Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Recipe Redesign: There Is No Box, Only Possibilities

Bekka Ball — Thu, 10 Apr 2025 17:00:00 GMT

I have always loved cooking. I learned from my Grandma June and her kitchen was her sanctuary, a small, warm sunlit space filled with jars of spices, stacks of cookbooks, and the comforting smell of something always on the stove or baking in the oven. Grandma June was as great a cook as she was a teacher to me. She never followed a recipe “to a T” and if you wanted one of her recipes then you stood in the kitchen behind her and wrote down ingredients, guessed at how much she used and documented the steps.

Grandma never felt trapped by the steps in the cookbook, boxed in by the precise measurements and strict instructions. It wasn’t that she didn’t understand the recipe, it was that the recipes didn’t leave room for her own ideas. She’d always believed recipes were suggestions, not rules and I loved that about her. She trained her taste to know when something was seasoned enough or if a flavor was missing, her eyes to know when it was mixed just right, and her nose to discern when it was ready.

That’s why I loved standing shoulder to shoulder with her learning to make her biscuits, pies, cornbread and famous soups, stews, and casseroles. See, my Grandma June taught me more than just cooking she taught me how to be creative, innovative, and agile at improvising. It was common for her to swap an ingredient for something else, just because she had it left over.

She would often rummage around her kitchen with a mischievous smile curling up the corners of her mouth and say "Darlin', don't you worry if your pantry's lookin' a bit bare. A true cook knows that the best recipes come from a sprinkle of ingenuity and a whole lotta heart. Just mix and match what you have, and you'll whip up somethin' that’s finger-lickin’ good!"

I would watch her add a pinch of this or a dash of that just because she could see the potential in it. I would silently wonder “What if it’s awful?” or “What if we messed it up?” But when the timer dinged and she pulled her creations out of that old olive-green oven, the aroma that filled the kitchen was unlike anything I’d ever smelled. She would cut us a little slice to taste, and my eyes would sparkle, and my tastebuds would rejoice. It wasn’t perfect, it was better. It was hers.

Thanks to Grandma June, I stopped treating recipes as rules and started seeing them as inspiration. In the many years following, I played with flavors, combined unexpected ingredients, and embraced the occasional disaster just like she taught me. My cooking became an adventure, and people started asking for my “recipes” which no one could ever quite replicate.

The experience taught me something bigger than cooking; that creativity isn’t about following someone else’s steps perfectly. It’s about trusting yourself to step off the path and make something uniquely yours. After all, there’s no constraints in the kitchen, only the ingredients you’re brave enough to try.

We’ve all heard the phrase “think outside the box,” a well-intentioned mantra designed to spark innovation and push boundaries. But what if I told you there is no box? What if the so-called “box” is just a myth, a self-imposed limitation born of convention and fear of the unknown?

Creativity doesn’t thrive within neatly drawn lines or pre-approved structures. It’s messy, unpredictable, and, above all, limitless. By letting go of the idea that creativity requires escaping a box, we can reframe the way we approach ideas, problems, and opportunities.

The Box is a Comfort Zone in Disguise

The concept of the box represents comfort zones, societal norms, and traditional ways of thinking. It’s the voice that says, “This is how it’s always been done” or “Play it safe.” How many times have we heard that at work, but true creativity doesn’t flourish in safety. It blooms in the daring leap, the bold experiment, the failed attempt that births a breakthrough.

Ask yourself: Is your creativity constrained by imaginary boundaries? Perhaps you’re waiting for permission, resources, or the perfect moment. The truth is the box only exists if you believe it does.

Without a box, you’re left with the raw materials of potential: ideas, inspirations, and challenges. It’s up to you to assemble these pieces into something meaningful. Creativity is less about having all the answers and more about asking questions:

What could this become if I approached it differently?

What assumptions am I holding that no longer serve me?

What would I try if failure didn’t matter?

The beauty of embracing this mindset is that nothing is wasted. Every misstep, discarded concept, or seemingly random thought becomes part of a greater tapestry.

Imagine walking into a wide-open space instead of staring at a small cardboard container. Suddenly, there’s room to explore, to pivot, to let your curiosity lead. When you stop looking for the box, you free yourself to experiment in ways you never considered.

One way to do this is by blending ideas from unrelated fields. If you're project is focused on finance, explore marketing strategies; if you're deep into data analysis, investigate customer behavior trends. The most innovative solutions often appear at the intersection of diverse disciplines.

You don’t need to be a prodigy or a visionary to embrace boundless creativity. It’s not about innate talent; it’s about cultivating a mindset of openness and playfulness. Give yourself permission to take risks, to fail spectacularly, and to start again with a better perspective.

Here are some practical tips inspired by my Grandma June to help you kickstart your no-box mindset:

1. Break the Rules – Challenge the norms of your industry or field. What rules could you bend or rewrite?

2. Embrace Constraints as Catalysts – Constraints often spark creativity by forcing you to think differently.

3. Collaborate Widely – Different perspectives can dismantle old ways of thinking.

4. Stay Curious – Curiosity is the antidote to stagnation. Explore ideas and subjects you know nothing about.

When you stop searching for the edges of a box, you discover the infinite possibilities of the space around you. Creativity isn’t about escaping, it’s about exploring, building, and shaping something entirely new from nothing or innovating something that exists into something more useful. Innovation is a powerful means to drive business and your career. Finding ways to challenge our brains to see things in a new way is the skill needed to achieve this goal. Whether you’re finding new ways to use ingredients or changing major business processes, challenge your mind to see things differently, and act passionately about these innovative ideas to create change. You always possess the ability to be an agent of change and it’s up to you to act on it. Use your mind to draw connections among questions and never settle for good when exceptional is available and waiting for you to grasp it.

So, the next time you hear someone say, “Think outside the box,” remember, there is no box, only the endless potential of imagination. The box is a metaphorical vault for creativity that society has forgotten how to access. There’s just you, the pieces of your imagination, and the endless potential to create something extraordinary.

It's about envisioning what can happen when you stop thinking about how things are supposed to work and start thinking about how they could work. My Grandma June showed me this in her kitchen, teaching me that creativity isn't about breaking out of the box. As she would say, “Every recipe has a secret ingredient just waiting to be discovered."

Top 20 Crucial Angular Best Practices to Embrace in 2023

Nikunj Shingala — Thu, 10 Aug 2023 16:14:00 GMT

Angular is a powerful open-source web application framework developed and maintained by Google. It is designed to simplify and streamline the process of building dynamic and interactive web applications.

Angular was first introduced in 2010 as "AngularJS" by Misko Hevery and Adam Abrons during their work on a project called "GetAngular." It gained significant traction in the web development community due to its innovative two-way data binding and declarative approach to building user interfaces.

With its robust features and comprehensive set of tools, Angular has become one of the most popular frameworks for front-end web development. Angular has become one of the most popular and powerful frameworks for building dynamic and scalable web applications.

Angularjs development services have continued to evolve, with regular updates and new versions released to provide developers with cutting-edge features and tools to build complex web applications with ease.

Key Features of Angular

Component-Based Architecture: Angular follows a component-based architecture, where each UI element is represented by a component. Components encapsulate the HTML, CSS, and logic, making it easier to manage and reuse code.
Two-Way Data Binding: Angular offers powerful two-way data binding, allowing changes in the model to automatically update the view and vice versa. This feature simplifies the synchronization between the data model and the user interface.
Directives: Directives in Angular enable developers to extend HTML with custom elements and attributes. Built-in directives like ngIf, ngFor, and ngStyle enhance the development experience and make the code more expressive.
Dependency Injection: Angular's built-in dependency injection system facilitates the management of application components and their dependencies, promoting modularity and testability.
Routing: Angular provides a robust routing mechanism, enabling developers to create single-page applications (SPAs) with multiple views and navigation without reloading the entire page.
Forms: Angular offers two form handling approaches: Template-driven forms and Reactive forms. These features simplify form validation, data binding, and form submission.
RxJS Integration: Angular integrates seamlessly with RxJS, a reactive programming library that enables efficient handling of asynchronous operations and event streams.
Cross-Platform Development: With Angular, developers can create not only web applications but also cross-platform mobile applications and desktop applications using tools like NativeScript and Electron.
Angular CLI: The Angular Command Line Interface (CLI) provides developers with a set of powerful tools to scaffold projects, generate components, services, modules, and handle the development workflow efficiently.
Angular Material: Angular Material is a UI component library by the Angular team, implementing Material Design guidelines. It offers a suite of pre-built, customizable components to enhance the look and feel of applications.

Top Angular Best Practices to Adopt in 2023

As we venture into 2023, it's crucial for developers to stay up-to-date with the best practices in Angular to ensure efficient and maintainable code. Let’s explore the top 20 Angular best practices to adopt in 2023, enabling you to deliver high-quality applications and enhance your development workflow.

Use Angular CLI

Angular CLI (Command Line Interface) is a powerful tool that streamlines the process of creating, testing, and deploying Angular applications. Utilize Angular CLI to bootstrap projects, generate components, services, and modules, as well as for efficient code scaffolding.

Upgrade to the Latest Angular Version

Staying up-to-date with the latest Angular version is essential to access new features, bug fixes, and security updates. Regularly upgrade your Angular projects to ensure they benefit from the latest improvements.

Follow the Single Responsibility Principle

Adhere to the Single Responsibility Principle (SRP) when designing components and services. Each component should have a single responsibility, making the codebase more maintainable and easier to debug.

Optimize Change Detection

Angular's change detection is a powerful mechanism, but it can also lead to performance issues. Use OnPush change detection strategy judiciously to minimize unnecessary checks and improve application performance.

Lazy Load Modules

Employ lazy loading to load modules only when they are required, reducing the initial load time and enhancing the overall application performance.

Use AOT Compilation

Ahead-of-Time (AOT) compilation helps to reduce the bundle size, leading to faster loading times for your application.

Follow a Consistent Folder Structure

Organize your Angular project with a consistent folder structure to maintain a clear separation of concerns and ease collaboration among team members.

Leverage Reactive Programming

Use RxJS to implement reactive programming in Angular, enabling efficient handling of asynchronous operations and simplifying data flow management.

Minimize the Use of ngIf and ngFor

While ngIf and ngFor are handy directives, overusing them can negatively impact performance. Minimize their usage, especially when dealing with a large number of elements.

Implement ARIA Accessibility

Make your Angular applications more accessible by implementing ARIA attributes and following accessibility best practices.

Optimize Bundling and Tree Shaking

Leverage tree shaking to remove unused code from your bundles and optimize the application size for better performance.

Proper Error Handling

Implement robust error handling mechanisms to provide meaningful error messages and avoid crashes that could negatively impact the user experience.

Use Angular Interceptors

Angular interceptors are great for handling HTTP requests and responses centrally. Utilize them to add headers, handle errors, and manage loading indicators.

Apply Angular Forms Effectively

Angular provides powerful form handling capabilities. Ensure you're using template-driven or reactive forms appropriately based on your application requirements.

Perform Unit Testing

Write comprehensive unit tests for your components, services, and directives to maintain code quality and reduce the chances of regressions.

Implement Server-Side Rendering (SSR)

For improved SEO and performance, consider implementing Server-Side Rendering to render Angular applications on the server side before sending them to the client.

Utilize Angular Material

Angular Material is a UI component library by the Angular team. It provides a set of ready-to-use components that follow Material Design principles, speeding up development and maintaining a consistent look and feel.

Keep Third-Party Libraries Updated

Regularly update third-party libraries and dependencies to avoid security vulnerabilities and benefit from the latest features and bug fixes.

Implement Content Security Policy (CSP)

Employ Content Security Policy to protect your application from cross-site scripting (XSS) attacks and improve its security.

Monitor Application Performance

Utilize tools like Angular DevTools and Lighthouse to monitor and optimize your application's performance continually.

Conclusion

By embracing these top 20 crucial Angular best practices in 2023, you can enhance your development workflow, build more efficient and maintainable applications, and keep up with the ever-evolving Angular ecosystem. Staying vigilant about updates, security, and performance optimization will help you create cutting-edge web applications that provide an exceptional user experience.

From startups to enterprises, businesses across the globe are leveraging AngularJS development services to build scalable and robust applications that engage users and enhance their online presence.

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

What Skills do You Need to Become a Business Analyst?

Digvijaybook — Wed, 27 Nov 2019 09:58:00 GMT

IT companies are rapidly looking or adapting modern methodologies, so the business analyst role is increasing day by day. Offline is shifting to online, and this is why today, companies can easily garner important data in any aspect. But, data itself has no meaning hence, organizations look for a business analyst who can analyze the data and draw actionable items out of it.

Some IT jobs have defined responsibilities but the role of a BA always changes means a business analyst professional may work as a project manager, process manager, IT manager or in product innovation. In the modern technology world, BAs are using multiple technical solutions and tools to generate result-oriented solutions. Some most frequently analyst tools are – Python, R, Excel, Tableau, etc.

Business analysts can be a part of any type of organization such as private, government or non-profit. Depending on the nature of work and organization type, job functions of business analysts may vary but the key objective of their job remains the same i.e. to understand the existing business processes and operational activities and to develop such solutions that can improve the overall business model for better performance and productivity. They work with the management team, show them the current picture of all the organizational processes and share new ideas with them for how to improve the revenue, cut the unnecessary cost and achieve a competitive edge in the modern market.

Some business analysts work as external consultants on a contractual base, they perform targeted analysis and basis this provides important suggestions to companies for boosting sales and improving productivity. Such BAs are expertise in specific fields such as health, IT, business, supply chain industry, etc. Businesses that want to move in the foreign market or incorporate a new strategy – involve business analysts for meaningful contributions.

Modern Business Analysts

Business analysts in today’s world have responsibilities in multiple directions. Their prime role is to collect all the business requirements and prepare a solution for all by proper utilization of resources. The main qualities of BA are strong communication skills, result-oriented analysis, team player and robust process creator. In addition to this, a good analyst has a basic knowledge of all areas like sales, marketing, architecture, finance, etc. In simple terms, a business analyst is like a bridge between the business process and technical solution development means he is responsible for developing solutions with the use of technologies & tools for solving business problems.

The Job Role of a Business Analyst

As you go into the details of how a business analyst works, you will explore many facts regarding the job role of a business analyst. Not only a BA has good communication and analytics skills but it also, use numerous technical tools in day to day life. They take care of various development processes that help overcome the gap between two departments of an organization. The major responsibilities of an analyst are – identifying opportunities to improve business process & productivity, optimizing the business model by designing new business concepts, communication with management team & SMEs to understand the actual issue, collecting & documenting the details of requirements and analyzing it, designing technical solutions for business problems, interacting with architects & developers to check If implementation is done correctly, and creating the user manuals.

How to become a Business Analyst?

Now you have a good understanding of what is a business analyst role and how they work. Let’s move ahead with the path you should follow and the academic qualifications that you require to become a business analyst. There is one fact which is very important to keep in mind is that not all the qualification mentioned to be a BA is important rather many people switch from different fields to analytics and make a stable career too. Let’s discuss what you need to become a highly-paid business analyst professional.

Educational Qualifications

You must have a bachelor’s degree to get an entry-level business analyst job. Since many degrees are designed specifically to offer training for business analysis, therefore, many organizations look for candidates having a degree in business analytics. The most demanding courses for this profile are business analytics, business administration, operation management, etc. For the senior or consultant position, companies look for candidates having a master's degree in business analytics or business administration. People who start their career as junior analysts barely go back to join a college for get the Master’s degree but it doesn’t mean that they can’t work as a senior analyst. Master’s degrees is just a standard but many junior profile professionals get experience, knowledge, perform better in their current roles, and get a senior position without any Master's degree.

Certifications

Let’s discuss the topmost certifications that increase the opportunities for you to get a job as a Business analyst at a handsome package.

Certified Business Analysis Professional (CBAP)

The International Institute of Business Analysis provides CBAP certification. To be a Certified Business Analysis Professional, a candidate has to complete a training session of the duration of 21 hours about professional development, as well as he has to pass a written examination. This certification is designed for experienced people only means it is helpful to achieve a higher position in the industry.

Certified Management Consultant (CMC)

The Institute of Management Consultants USA provides this CMC designation. This professional certification is designed especially for experienced business analysts who are working as a consultant. However, the institute provides basic certifications to candidates with bachelor’s degrees only. to get a Certified Management Consultant, you will need to pass an oral as well as one written examination. This analyst certification is very helpful for getting a senior analyst position in big consulting firms.

Scope of Business Analytics Career

The business analytics role is multifaceted, so are the positions. A business analyst is a permanent & most-demanding job role in top MNCs, whereas small to mid-sized organizations hire consultants on a contractual basis to improve the process and productivity of their companies. All the top companies such as Amazon, Flipkart, TCS, Cognizant, Wipro, American Express and many others set a hiring process for business analytics profiles. Now, coming to the remuneration part of a business analyst, it is a well-known fact that business analyst professionals are one of the highest-paid employees of an organization.

Conclusion

If you have the minimum required qualification equipped with the skills stated above, you can easily follow a path that certainly would help you become a successful business analyst. Since most companies are planning to expand in the foreign market, hence, they are looking for BA professionals who can help them execute this process effortlessly. Many skilled candidates want to be part of this dynamic move and make their careers in business analytics, develop these skills, and come forefront to be part of it!

Sections in a Functional Layout for an Entry Level Job Resume

Alice Bolingeryn — Thu, 18 Apr 2019 10:54:00 GMT

Clearly, the most important step in getting a job is being selected for an interview, and a key part in that process is having a resume that stands out from others. For many people, creating a good enough resume is an obstacle in achieving this, and so one way to address this problem may be to get a professional to create one for you. Job professional cv writing services will have staff that focus on this type of writing every day. They will have the experience in preparing resumes for tens of thousands of job seekers in diverse situations. One distinct advantage in using professional services is that you're benefit from having a trained professional prepare a critical document for you. This may include improving the layout, create powerful statements and tailoring your resume to the industry you want to work in.

Career objective
This outlines your career goals and should be tailored to the position you want, show how you mean to apply your qualifications to this position as well as how you hope to develop your experience.

Education

As shown in the sample above, next is the education section. Simply provide the institution attend, its location, the year you graduated and academic discipline. If you attended a North American college/university can include your GPA or if it’s a USA university, provide your degree class.

Professional Skills
In this section you need to provide sub-headings as they relate to the qualifications you want to promote. This will vary, however if for example, you’re applying in response to a job ad, look at the job specification and see what skills they are asking for. By doing this, you can begin to build a skills profile based around the job spec requirements. Include your part time jobs, internships, volunteer positions, community service work, or school activities.

Work Experience/Work History
Only include this section if you’ve had any part-time jobs while during your studies or have had internships/work placements you'd time to make the employer aware of. Here, include how long you’ve worked in the jobs, the name of your previous employers and where they were located. You do not need to detail what you did in these positions, as you should be outlining the most pertinent skills used in these jobs in the previous section.

Activities
If you were or are a member of any societies, organisations or have any relevant interests, only include them in this part if you feel that is supports your career objective. For example, if you were a web editor for your school’s website and attempting to get in at a publishing company, make sure that you include this experience.

References
This is the final section in the functional layout for an entry level resume. Even as a recent graduate, it’s still important to supply references on your resume. By having someone to vouch for your character, it gives the employer additional information needed to consider you as a qualified candidate. Furthermore, it will definitely boost your application.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Every Business Analyst Must Negotiate Like a Pro

Adrian M. — Wed, 11 Feb 2015 00:45:00 GMT

In the larger context of life, it is very clear that negotiation skills are very important and that those that have them are better off than those who don’t.

What about in business analysis? Are negotiation skills important?

The answer is an emphatic: YES! You bet they are!

Business analysts negotiate or facilitate negotiations at every turn. At the very infancy of a project, negotiation skills are used to determine what should be included in the vision of the project, in the project charter.

As details emerge, negotiation skills are used by all parties involved to determine which requests become requirements and which requirements have higher priority.

As the project progresses, negotiation skills are again used to determine the functional design which fulfill the requirements. Technical decisions also require negotiation skills.

While it would be much easier if project decisions were black and white (objective) the reality is that everything is negotiable.

So – if you are a business analyst or systems analyst make sure to add negotiation skills to your repertoire.

Certain individuals are great negotiators from birth, the rest 95% of us need to work on these skills.

We can’t afford not to!

By now you might be wondering if you can do it – if you can be an effective negotiator!

Yes! You can negotiate anything!

Here are some tips and guidelines to help you get started. These are really the notes I jotted down while reading “You Can Negotiate Anything!” a great book by Herb Cohen.

Definitions

Negotiation = activity in which parties are trying to satisfy needs.

Process of Negotiation = It is a way of acting and behaving that can develop understanding, belief, acceptance, respect and trust. It is the manner of your approach, the tone of your voice, the attitude you convey, the methods your use, and the concern you exhibit for the other side’s feelings and needs.

Negotiation Myths

MYTH # 1: We want the same thing therefore if you win I lose
The majority of us think of negotiation as a pie that needs to be divided. Therefore if you get the bigger piece then I get the smaller piece. If I win then you lose. The reality is that needs are not always in opposition: In most negotiating situations, the needs of the two parties are not really in opposition. In a collaborative Win-Win negotiation we are trying to produce an outcome that provides acceptable gain to all parties.

MYTH # 2: Money is the most important thing to the other party
While money is not everything in life, it surely nice to have lots! Deep down each one of us think of negotiation in terms of money. Money seems to be an easy and objective way to keep score and to decide if I negotiated a good deal or not.

The reality is that money is not the only need. If you think most negotiations pivot around money, then you’re mistaken. Money is a need but is only one of many. If you neglect their other needs, satisfying people’s dollar need alone will not make them happy.

MYTH # 3: The other party told me what they want
Most of us assume that the other party will or have already clearly communicated to us their needs and wants. The reality is that the real needs of the other party are often not considered for a number of reasons. Negotiations are never totally about what is being openly talked or contested, be it price, services, products, territory, concessions, money, etc – because negotiators try to conceal real needs or don’t recognize them.

Many folks use negotiations as way of satisfying deeper, often subconscious, needs such the need to be appreciated, wanted, and recognized. What is being discussed, and the manner in which it is being considered, are used to satisfy psychological needs.

Win-Win Negotiations

PRINCIPLE: Negotiate for Mutual Satisfaction (Win-Win)
If there is only one thing that you get out of this article is the importance of having a win-win view of the negotiation process. Successful negotiators view the opposing party as colleague rather then an opponent.

The goal at the end of the day is for the parties to shake hands and say something like “That was fun and mutually benefiting! Hope we get to do this again sometime!”

Therefore, your goal and mindset in any negotiation should be to:

Use the process to meet needs (the other party’s needs)
Harmonize or reconcile needs (yours with the other party’s)
Watch for and avoid conflicts which stem from differences in experience, information, and role.

More tips to achieve win-win outcomes for the business analyst:

Build Trust - Find out as much as you can about the other party needs and wants, show genuine concern for the other party’s welfare, and transform the relationship in to collaboration.
Don’t make enemies – As a business analyst you interact with people possessing various levels of knowledge. If you know more or understand it better don’t forget the power of your attitude – check your own ego at the door.
Communicate your needs – Many of us do not succeed at negotiations because we don’t make our needs known. The squeaky wheel really gets the grease, if it knows where, when and how to squeak.

The bottom line is that as a business analyst or systems analyst, you can’t afford not to learn how to negotiate. Learning to be a good negotiator takes time so start now.

If you don’t plan on making a conscience effort to improve your negotiation skills through practice, reading, courses, etc., then keep this on thing in mind… try to help the other person win, make them successful, they’ll remember you.

Another way to put this is summarized by the golden rule: “treat others as you would like to be treated.”

If you do this you’re well on your way to many successful negotiations.

Adrian

From Developer in India to Business Analyst Abroad

Adrian M. — Wed, 28 Jan 2015 12:19:00 GMT

Business Systems Analyst as a Career Option

If you are an IT professional in India, thinking of working abroad, you might want to consider a business/systems analyst position.

Why?

It’s a position in high demand with high earning potential and which can serve as a great foundation for moving up the corporate ladder into management or business operations.

In on of Money Magazine’s Best Jobs in America list, the Computer/IT Analyst career was ranked 7th, out of 50 best jobs, with a 10-year job growth of 36.10%.

In one of their “Best Careers” report, US News and World Report lists 25 professions that will continue to grow in demand. With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list - however systems analyst is.

All industrialized nations are heavily outsourcing the programming of software to other parts of the globe such as Russia, India, China, Eastern Europe, and South America.

While there’s still demand for developers, of course, the information economy has created an ever increasing need for business analysts and systems analysts.

As a matter of fact, the very outsourcing of programming jobs has caused a spike in the demand for business systems analysts. The increase distance between the business stakeholder and the programmer has created an increasing need for higher quality and more precise analysis artifacts such as requirement documents and functional specifications.

In addition – in a more an more competitive economic landscape business organizations continue to strive to improve their business processes and reduce costs. Business analysts are at the center of most of these initiatives.

So are you ready to make the move?

Before you take the plunge, you should do a quick self assessment to determine if the business analyst role might be a good fit. You’re probably a good candidate if:

you don’t want to spend the rest of your career in front of a monitor debugging code,
you love to talk to people and socialize,
you not only love to talk to people but you are actually a good communicator,
you are good at organizing information in a structured and concise manner for others to consume,
you want to, and are able to, grasp the big picture,
you are fascinated by how companies actually make money, about the business systems and processes in place.

OK… so if you still think that business systems analysis is for you, then let’s take a quick look at what you need to begin a career as a business/systems analyst.

For starters, if you are a developer you already have a great advantage:

you think in a structured manner,
technology is not magic but something you actually understand,
you are most likely used to working in a variety of industries,
lack of detailed business knowledge causes you to ask very relevant “why” questions,
you know how to talk to the technical side, and
you probably have already been reviewing artifacts created by the business analysts.

So what’s next?

If I were forced to pick the top two skills or abilities that a BSA must have I will always pick strong communication skills and analytical (structured) thinking.

Communication Skills

The first thing you need to focus on is communication skills. No matter how good your communication skills are you can always learn more. This is a must have skill for the business systems analyst.

If you are assessing your abilities and trying to figure out which aspect of communication to work on next, here are some areas to consider (pick the one in which you are the weakest and run with it):

ability to verbally communicate your thoughts and ideas to others and make yourself understood,
ability to understand others and to ask relevant questions which cause the other party to give you the information you are looking for,
ability to write clearly and in a concise manner (when creating analysis artifacts - less is more)

Analytical/Structured Thinking Skills

The next thing is structured (logical) thinking… this is one of those aptitudes which, at some level, I almost want to categorize as “you either have it or you don’t.” However I haven’t yet found conclusive evidence to support my claims – not yet.

So for now, work on improving your analytical and problem solving skills as without them, you will fail as a business systems analyst or, at best, you will be a technical writer with a BA title.

If you are assessing your skills in this area you might want to consider focusing on the following:

techniques which help you organize your thoughts or the facts about a given problem,
methods of making a problem more manageable such as: divide and conquer, abstraction, problem solving patterns,
formal reasoning skills such as: propositional reasoning, identifying and controlling variables, suppositional reasoning, etc.

For more details check out Mind Tools, a good resources of ideas and techniques to improve your analytical and structured thinking skills.

Keep on Learning

While I would argue that a software developer/programmer with strong communication skills and great analytical/structured thinking can easily land a business/systems analyst job, there numerous other abilities and skills you should develop if you plan to make business analysis a long-term career.

Here are some things to think about:

Requirement Elicitation Methods – as a business analyst you will be eliciting requirements from the business stakeholders therefore it will serve you well to become familiar with various requirement gathering techniques such as: end-user interviews, job shadowing, questionnaires, etc.
Vertical domain knowledge – if you are interested in a given industry (ex: mortgage banking, pharmaceutical, etc.) or if you already have previous experience in a given industry you should consider beginning your business analyst career in that industry. Of course – learn as much as you can as the more you know about a given business domain the more effective you will be as an analyst.
Knowledge popular modeling techniques (activity diagram, sequence diagram, data flow diagram, workflow/process flow diagram, etc.)

Adrian

Oh...I wish I knew this before!

Praveen Udupa — Mon, 23 Dec 2013 13:17:00 GMT

A few years ago, I had shifted with bag and baggage to the US. I thought that the upcoming project would consume me for at least a couple of years. Alas, that was not the case. I returned home in five months. Well, I don't even want to begin to think about the financial and emotional set back that my family and I had to endure!

Why did this happen? The easy answer is always, "Oh! you know, the customer was totally ill-prepared. They did not even have the business case for the project and they had already spent $1M+. Can you believe that? Ultimately the CEO found out that there was no business case and revoked funding." But this was only one of the reasons. There were several others. Among the others, one of the reasons was, well, me! I might have been the reason for the project getting scrapped!

You see, like in every project, there were two critical stakeholder roles for this project - the Sponsor and the Solution Owner. The sponsor was the head of IT. He controlled the budget. The solution owner was a director of a business division and he controlled the solution's features. In most projects, these two roles are played by the same individual. But in this project, these two roles were played by two different individuals.

The PM, the Solution Architect and I were clear - go to the sponsor for budget, estimate approval, release plan and timeline. "Please the sponsor" was our motto. We went to the solution owner only for requirements sign off and kept him out of the loop for discussions on release planning. Here lies the problem!

These two individuals acted based on completely different set of motivations - having just got out of the debacle of a long drawn, several times over budget project, the sponsor wanted to show quick wins by having shorter release cycles, which meant that the budget per release was very limited and thus the features we could accommodate in a release was limited. The solution owner, on the other hand, maintained that each release should be of value to the end users. There is no point in releasing something which the end users would find unexciting. For him, the definition of quick win was not just to make a release, rather to make a release that would win accolades from the end users.

You may imagine what happened next - the sponsor and the solution owner never saw eye-to-eye. That they belonged in two different organizational units and did not have to regularly communicate with each other only exacerbated the situation. I would work with the PM on developing a release plan, estimates and project plan. We would then take it to the sponsor. He would look at it and instruct us to reduce the number of features and hence the estimates. We would do that. He would then approve the release plan. I would then go to the solution owner, who would look at the release plan and literally go ballistic. I would plead helplessness and indicate that I was at the mercy of the sponsor. He would care for none of that.

Eventually, I raised both my hands. I said, you guys work with each other and resolve your differences. Well, I'll tell you something. They did resolve their differences. They had the project scrapped!

Was it my problem that the sponsor and solution owner did not get along? Is there anything that I could have done better? For both questions the answer is a resounding "Most certainly!" If only I had anticipated this tussle between stakeholders! If only I took a more proactive and a hands on approach to diffuse the tension between these two stakeholders. If only, if only...now do you get how I was one of the reasons for the project getting scrapped?

What could I do better? Stakeholder Analysis is a best practice that every BA must have mastery over. Alas, I studied this concept only after I returned from the US feeling like a hapless victim.

The purpose of stakeholder analysis is to analyze the interest and influence of each stakeholder and customize our collaboration strategy with each stakeholder with the sole intention of minimizing the adverse impact on the delivery of the solution. Stakeholder Analysis enables the BA to deal with stakeholders as a matter of choice rather than chance!

So, let's talk about stakeholder management:

Who is a stakeholder?

Stakeholder is anyone who is directly/indirectly, positively/negatively impacted by the problem and/or its solution. It is possible that someone is 'positively' impacted by the problem, in fact they might thrive and flourish inside the problem.

What is Stakeholder Management?

Stakeholder Management is about customizing collaboration strategies to suit the temperament and background of each stakeholder with an intention to "minimize the any adverse impact on the progress of a project" that could caused by a stakeholder.

Step 1: Stakeholder Identification

The first step in Stakeholder Management is obviously identification of all stakeholders. This activity begins as soon as the business needs are identified.

It is important, well, to make sure that all relevant stakeholders' views have been considered in building the solution. The BABOK lists various stakeholder roles that can be used to identify stakeholders. But this is easier said than done. For e.g.

Consider the stakeholder role 'Regulator'. Most of us assume this to be the macro regulatory bodies like SEC, SEBI, FDA, TRAI, IRDA, FSA, etc. But somehow we forget that PMO of an organization is also a regulator - they regulate what, how and when project deliverables need to be produced.
Consider Enterprise Security team. They regulate access to all 'Applications' in the enterprise, including the one that you are defining requirements for. Not only that, they also dictate security related requirements.
Consider Sponsor - the one with the money is the sponsor. We all know that. We assume that the sponsor needs to be pleased all the time. Well, this is not true always. It is not JUST the sponsor that needs pleasing...there are other stakeholders. One of the most critical stakeholders that need to be closely managed is who I call "Business Owner" a.k.a Solution owner. (The BABOK does not call out a separate stakeholder role called solution owner. I assume they include this in their Domain SME.) The Solution Owner decides what features and functionality should the solution provide and also has a say in release planning (i.e. when does which feature become available in the solution. Fair, right?) Normally, there is one individual that sits in the roles of both Sponsor and Solution Owner. This is the best case scenario. The troublesome scenario is when these two roles are played by two different individuals, like in my case (described earlier).

Step 2: Stakeholder Analysis

The second step is stakeholder analysis. This comprises of two parts - understanding a stakeholders 'interest' and understanding a stakeholder 'influence'. Let me dwell on these two points:

1. Stakeholder Interest

It is important to understand stakeholder's interests because it gives us some indication on how much would the stakeholder care about exercising whatever influence s/he might have. Interest is a function of two factors - change appetite of the stakeholder and impact of the solution over the stakeholder.

Change Appetite is the disposition of the stakeholder towards the change. In other words, to what extent is the stakeholder willing to change.
Impact of the solution is to what extent will the solution force the stakeholder to change

Stakeholder Interest is determined as follows:

Change Appetite	Impact of Solution	INTEREST
High	High	HIGH
High	Low	LOW
Low	High	-ve HIGH
Low	Low	LOW

Notice that if the Change Appetite is Low and Impact of Solution is High, the stakeholder will have a NEGATIVE interest in the project, which means that the stakeholder will not hesitate to scuttle the progress of the project or even kill it, provided s/he has adequate influence.

2. Stakeholder Influence

Stakeholder Influence is very simple. It is the degree to which the stakeholder can sway decisions to his/her line of thinking and impact the outcome of the project.

Step 3: Stakeholder Map

The third step in Stakeholder Management is to develop a visual model of stakeholder's interest and influence, which is called a stakeholder map. It looks like this:

Each stakeholder gets assigned a quadrant, with the relative location in the quadrant indicating the extent of influence / interest of the stakeholder compared to other stakeholders. The RED circles indicate the stakeholders who have a negative interest.

"Okay...this is great", I hear you saying. "Now what do I do? What significance do these quadrants hold? What is this about one stakeholder Bob moving from one quadrant to the other?"

A stakeholder map is the four quadrant Interest vs. Influence map. All the stakeholders fall into one of these four quadrants.

What do these quadrants represent?

The I Quadrant (top right) carries the most significance because the stakeholders who are high on both Interest and Influence are bracketed here.

But, mind you, the folk with negative Interest (the RED circles) can appear in the I and IV quadrants only...guess why?

What do I do with this map?

The stakeholder map essentially helps the BA figure out how the collaboration with the stakeholders should be.

I Quadrant - Manage Closely

High Influence & High (Positive) Interest

Work in Collaboration/ Partnership and keep on board.
Manage them closely and maintain support
Refine communications to align with project goals.
Leverage stakeholder influence.
Use in project teams to deliver change.
Reward their support.
Use an interactive communication method - do not use a dictatorial tone with them. Make them feel that every idea is theirs

High Influence & High (Negative) Interest / Resistance

Build Relationships when possible. Take time to know them.
Understand the underlying reasons for resistance. Paint a picture of the future if things continue as is.
Acknowledge their concerns.
Compromise on strategy where it is possible - give and take negotiation
Stand firm on principles and the need for change
Involve other influencing people who are more positive in influencing them
Use an interactive communication method - do not use a dictatorial tone with them. Make them feel that every idea is theirs

II Quadrant - Keep Satisfied
High Influence and Low Interest

Keep them satisfied.
Send regular information about project but not constant involvement.
Ensure that they support the project.
Target communications to align with project goals.
Provide information to help them become supporters
Enthuse about change and sell the benefits.
Use an push communication method.
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence

III Quadrant - Keep Informed
Low Influence and Low Interest

Manage relationship passively - not necessary to seek them out. Be courteous and genuine when they pass by the hallway or in the cafeteria
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
Use a push communication method - no interaction unless asked for.

IV Quadrant - Monitor
Low Influence and High Interest

Consult or have a dialog
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
Empower them and protect their interests
Consider their advice and opinions...no need to bend backwards to accommodate, unless they are really important to the project
Remain in constant communication to ensure that no major issues are arising

Coming back to my situation

So, had I known the above stakeholder management method, rather, had I known its real significance, I would have realized that both my warring stakeholders - sponsor and business owner - fall under the I Quadrant. In hindsight, what could have saved the project is the following collaboration strategies:

Involve both the sponsor and the business owner in all status review meetings (I used to involve only the sponsor)
Facilitate communication between these two stakeholders to ensure that both of them truly understand each other's worlds and both realize that neither is acting with any vested interest, rather, both want the best from the project
Arrive at the Release Plan together, such that both stakeholders' interests are optimally taken care of and that both understand what they are giving up, if at all, and why
Create an atmosphere of trust that neither stakeholder give you any guidance/direction without the knowledge of the other.

Well...better late than never, right? I might have been partially responsible for losing the project, but I did learn a lesson from that.

Let me know what you think...leave a comment!

What do you do?

Pjbussol — Mon, 18 Nov 2013 23:14:00 GMT

“So, what do you do?” It’s quite probably the question I most dread being asked. It’s a fairly benign question but as a Business Analyst I feel compelled to assess and understand what I am really being asked before attempting to provide an appropriately pitched response to my inquisitor. I find myself scrambling for the right words whilst my inner-voice is assuring me that whatever answer I give will most likely be met with confusion and probably even a little irritation.

“I am a Business Analyst” I awkwardly mumble – blushing out of embarrassment for the both of us – whilst preparing for the inevitable follow-up question…. Don’t get me wrong, I love my job and can passionately talk about it. The problem is, unlike a Project Manager, for example, the role of a Business Analyst is not clearly defined – You've got to love the irony!

The Business Analysis Book of Knowledge (BABOK) includes a standard definition of what a Business Analyst does. However, every Business Analyst, Project Manager, Hiring Manager etc. will have their own understanding and set of expectations. The truth is I don’t do any one thing. On any given day I could be mediating a heated discussion between a solution designer and a CFO in the morning and in the afternoon ordering doughnuts for a design workshop (tip: a great way to prevent any future mediation!) Sure, a Business Analyst needs to be skilled in lots of things and may be accountable for producing this document or that document, but these things should not define us and are poor indicators of the value we bring to a project. Every successful project starts with an idea but what is ultimately delivered is often very different indeed. The idea matures and flourishes and it is the job of the Business Analyst to cultivate and manage this change. We navigate the project through its life-cycle. The Project Manager might be in the driving seat but we are certainly up there next to her, preempting bumps in the road, managing diversions and ensuring the passengers in the backseat continue to enjoy the ride. For me, being a Business Analyst is much, I imagine, like being a parent to a teenage son or daughter – we must be objective listeners, excellent negotiators, understand budgets, have a real grasp on finances and build strong relationships (sometimes with people we don’t necessary want to). We are protective, we are demanding, we are challenging and we are 100% invested in the success of our “babies”.

“So, what do you do?” it’s still a question that I dread being asked, but honestly, I normally just respond with “I work in IT”… That’s normally enough to stop any conversation dead!

Communication Is a Two-Way Street

Russell Brewer — Mon, 29 Jul 2013 10:37:00 GMT

Don’t you love clichés? I am sure your immediate thought when you read the title of this post was “Yet another blog telling me I need to listen more”. You’re probably right about half of it, you probably do need to listen more. We all need to listen more. But this thought doesn’t deal with the art of listening; it deals with a completely different form of communication.

Have you ever gotten that email that just looked so long you decided that reading the first two lines would probably tell you everything you needed to know? Have you gotten the document that your stakeholder spent hours preparing, and you spend two minutes skimming over?

I have heard that listening is a dying art. I have attended multiple training sessions on active listening and training sessions designed to make me a better listener. Maybe it is time for us (I am including myself) to remember that reading is a form of communication as well.

Section 9.9 of the BABOK v2 deals with document analysis as a technique to gather requirements. Let us all remember that documents aren’t just the latest process flow or the user manual sitting on someone’s shelf - a document is also that unopened or opened but not really read email that is sitting in your inbox.

If your stakeholder explains something to you, and you don’t listen, then you’re not communicating. If your stakeholder sends you an email that you don’t read, then you’re still not communicating.

Want to be an effective professional? Follow up!

Lee Grinberg, CBAP, PMP — Thu, 18 Jul 2013 17:34:00 GMT

Would you like to be perceived as effective? Want to succeed?

Make sure you follow up.

As a BA you are involved in several initiatives at different stages of development. What separates an average professional from an exceptional one is following up on tasks assigned to others on your projects.

I'm too busy, you say? I don't own the tasks, you say?

Well, like it or not the BA has the primary responsibility of making sure requirements are documented, verified, and validated. This involves input from many sources and it's imperative to get the information in a timely manner.

The benefits of following up include:

Your work will be done on time
People will not forget the assigned tasks
You will be perceived as effective

How will I find the time to follow up, you say? Build it into your daily routine.

When sending an email, flag your email for follow up at some later time. Most email programs have this feature.
When speaking with someone, send them an email summarizing the conversation and confirming next steps. Flag the outgoing email as a follow up item.
Most importantly, follow through and follow up when the email reminder comes up.

In Summary, following up will enhance your job by making you effective. Following up is easily done using your email program and having the discipline to act.

Good luck on your assignments!

How to identify a good (and bad) Business Analyst?

Kunal Jain — Sat, 13 Jul 2013 16:54:00 GMT

Over last 6 years, I have come across more than hundreds of analysts and have conducted almost equal number of interviews. Over this time, I have developed a knack of differentiating best analysts from good and good analysts from bad. If you face this challenge regularly, this post might help you.

So how do you differentiate between good and bad analysts?

Thankfully, it’s not that difficult. I have put a framework around how to judge an analyst. You can use the same to make your life simpler. This framework has it’s genesis in hiring guidelines at Capital One. I have modified it to include additional parameters which I use during interviews.

Structured thinking

This is the most important attribute that distinguishes a good analyst from bad. This attribute is not only required to be a successful analyst, it becomes absolutely critical for a person managing Business Analysts.

So what is Structured thinking?

Structured thinking is a process of putting a framework to an unstructured problem. Having a structure not only helps an analyst understand the problem at a macro level, it also helps by identifying areas which require deeper understanding.

How do I test for structured thinking?

Typically I test this by throwing a open business problem at an analyst and then observing closely how he / she is solving it.

An example is asking a question like: “You have been appointed as CEO of a loss making restaurant at Delhi / London Airport and you are expected to join the company in a week. What would you want to do as a CEO of the company as soon as you join them?”

If the person lays out a nice structure about where the problems could be, he has already ticked one box. If he starts giving you answers out of his hat (e.g. I would be looking at what marketing are we doing?), you should consider it as a red flag. He will not be able to sail through the world of Analytics.

Business understanding and problem solving

There is a reason why Business Analysts are called so and not just Analysts. Until a person understands what he is trying to solve and the business owners are confident that he can solve problems in meaningful manner, he is a dead analyst.

So, how do you test for business understanding?

For an experienced analyst, I typically start judging this by asking about business context for the projects he might have worked on. If he can explain that clearly, it’s a good start. If he can’t, you can almost make your hiring decision here. Next, you can look at the answers a person gives in response to question asked for judging structured thinking. If he gives answers based on numbers only, you need to probe him further. He needs to put a business thinking hat and provide some out of box suggestions.

Attention to details

If a person is not detail oriented, he can never be a good analyst. Every analyst should have the ability to understand business at high level, but he should be able to get down to nuts and bolts of all the levers you might have.

So how do you judge for attention to details?

Start by looking at the CV of a person, has he spent time choosing words carefully? Has he mentioned impact of the projects he might have worked on?

For an experienced analyst, probe on the projects he might have worked on before. Did he consider all the aspects and possibilities? How much time does take to explain his previous projects?

Another way to judge it is by asking the candidate to a guess estimate, something like “Estimate the number of smartphones used in India” and looking at how the candidate answers them. How many factors does he consider to come up with answers? How many segments does he consider to arrive at sizing? These aspects should give you a good read on how detail oriented a person is.

Ability to triangulate numbers & do back of the envelope calculations

While the first three characteristics help you identify a better than average analyst, this characteristic and the next differentiates best of analysts from good analyst. This is an activity I love to do and something I know every good analyst loves. This is the ability to set up equations on page and then do back of the envelope calculations to answer 80% of questions without touching any excel / calculator or laptop. It is also the ability to arrive at a number through various sources and then validating them.

How to judge ability to triangulate numbers and do back of the envelope calculations?

Guess estimate comes to your rescue here. Just ask the candidate to perform the guess estimate on a paper and then ask him to validate the number through an alternate approach.

Communication skills – Ability to tell stories based on numbers

Any analyst is only as good as he can communicate. If a person can not take the complex world of numbers and create a meaningful story out of it, he will always be looked upon as a nerd. He can be a good analyst, but not the best one. Ability to create a story and present it almost has an equal, if not higher influence on your customers and hence increases the chances of success of any analytics project.

How do you judge communication skills?

You can get a sense on this through the entire interview. If this is very critical to the role you are evaluating for, you can provide datasets in excel and ask the person to present some open ended questions

Hopefully, this framework will help you for any analyst hiring in future. In case you have some suggestions, do let me know.

Kunal Jain

Blogger, www.analyticsvidhya.com

kunal.jain@analyticsvidhya.com

Do you want stakeholders to trust you?

Lee Grinberg, CBAP, PMP — Mon, 03 Jun 2013 12:23:00 GMT

Do you want to be an effective BA?

The first step is to make the key stakeholders trust you.

As I wrote in my previous post it is the first step in establishing yourself when you're the only BA in your organization.

When I joined and sat down for my first meeting with the project team not only was I met with stares of hostility I was also leveled with questions regarding the need for my role (gasp!) The project sponsor and his right hand who was developing business requirements were feeling threatened and did not want to give up control.

So, how to make them trust you? Develop rapport and give credit!

First, develop professional rapport. Over a few months, I met with them to clearly establish my boundaries (writing functional specs) as opposed to stepping on their turf (business requirements) and to offer my help with clarifications whenever I could. I learned their business terminology and got my hands on as much system information as possible. In the process of developing rapport, I was also learning about the system and became a better BA. This went a long way to establish my earnestness and good intentions.

Second, develop a personal rapport. I got to know these guys pretty well. We had a few drinks, shared personal stories, and trust soon developed. I also asked them for help in navigating the organizational culture. When people help you, they trust you.

The final watershed moment that made them trust me happened in another project meeting. I was doing a presentation on the state of the project to senior management and when the time was right stopped and gave credit to the guys who started it and kept it rolling. I took no credit for myself. This completely established my good intentions.

So, what finally happened? These stakeholders and I have a great working relationship which outlasted the original project.

Applying Agile principles to requirement analysis

Ryan Thomas Hewitt — Mon, 27 May 2013 13:31:00 GMT

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase -> Requirement Analysis (Business Analysts/Product Owners)

Design Phase -> UX (Designers/Usability Experts)

Development Phase -> Software Development (Developers)

Testing Phase -> QA (Manual Testers and Developers in Test)

Delivery Phase -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”. This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes. Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirementcollaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

Are you the first and only one?

Lee Grinberg, CBAP, PMP — Sat, 25 May 2013 11:04:00 GMT

Are you the first and only Business Analyst in your company? If so, you know how hard it is to survive while doing your job and bringing about organizational change. If not, you may be frantically thinking "How do I get out?!".

This post is to share my experience in how to not only survive but thrive!

I joined a mid-size company where there was no Business Analysts or Project Managers. On top of this, the IT team was new with little knowledge of the system. There was an SDLC (sort of) that was being followed but the requirements gathering went something like this:

Business user wants something but he's not so sure what
He pops by the IT department and blurts it out to an unsuspecting developer
Developer codes something the developer is sure the business user wants
QA talks to the business user and developer to figure out what they really want to test (no test plan or testcases)
Go live date and the next few days - chaos as bugs appear and no one quite knows how this happened (again and again)

So by now you're thinking I was marching off to the SVP of the company with a copy of BABOK in hand in a self righteous indignation, right? WRONG.

Open confrontation would only create resentment on the part of the entrenched business and developer community. Instead I laid low for a while, observing taking notes and thinking where I would make corrections.

I made changes slowly following the steps below in order:

Developed relationships with influential stakeholders. Relationships go a long, long, way towards acceptance.
Started writing down requirements and showing them to the business stakeholders. Reactions were "Wow, you really got it" or "This is not what I meant at all, here's what I really meant....". That's the idea, get them to acknowledge what they really want.
Learned the database structure so that my requirements could refer to tables and even specific fields. I know, I know this is not what a BA should do but... with a new IT team it was best.
Produced a detailed spec which was the sole document used for development and QA. All stakeholders were now on one page.

The above was done on a small project. This way I didn't "rock the boat". Since the results were much better than the status quo, my perceived value to the business and IT went up a notch. Since I could now speak a little businessese and ITese I also got some respect.

There was much more to do of course and the four steps above are just general highlights. More details on how to implement them in further posts.....

What Every Business Analyst Can Learn From Journalism: The Art of Intelligent Questioning

Stephanie Famuyide — Sat, 02 Mar 2013 15:44:00 GMT

"Garbage in, Garbage Out" - To elicit accurate requirements, the business analyst must learn to ask the “right” questions “the right way”. The manner in which questions are delivered and the composition of these questions have a direct impact on the usefulness of the responses we receive.

If your questions are properly and thoughtfully framed, not only will you get the appropriate response, your stakeholders will also go away with a feeling that you indeed understand and empathize with them. They should come out of an interview session feeling “understood” not “interrogated”.

According to Donald Rumsfeld’s infamous (but accurate) quote in 2002 regarding the Iraq war:

“There are known knowns - things we know that we know.

There are known unknowns – things we know that we do not know

And there are also unknown unknowns – the things we don’t know we don’t know.”

The known knowns and known unknowns are easier to manage – by asking confirmatory questions to test the accuracy of existing knowledge and asking direct questions to elicit information on grey areas. How then should Business Analysts handle what they don’t know they don’t know? The answer is pretty straightforward:

By opting for open-ended questions.

Open-ended questions are more appropriate where you have limited knowledge on stakeholder issues or expectations. Questions that start with the 5 Ws and H: who, why, what, where, when and how tend to elicit more thoughtful and insightful responses when compared with those that start with: Would, Should, is, are, do you think, and the like.

For example, instead of asking: Do you open physical files for the different documents you receive? It’s better to ask: "How do you manage the documents you receive?"

Using the 5Ws and H also implies that you want to know what your stakeholders' opinions are and you're not just looking for an opportunity to state your own opinions through a leading question.

Feedback cycles, meet deadlines. NOT good bedfellows

theBetterBA — Sat, 08 Dec 2012 20:12:00 GMT

Its quite a feat of strength to pretend you don’t have any weaknesses. I don’t pretend to be that strong.

Its quite a bit easier for me to look for faults, gaps, misses, short comings, imperfections and details that spell out why something is not right.

Its a blessing and a curse.

Looking at my deliverables in this light is second nature to me. Seek out opinions. Get critique. Make your work better. Constantly strive to push yourself.

But how often is that process of seeking critique under as much scrutiny as our work? Is it not as important? The means by which we seek out advice, and how we incorporate it is a corner stone of our work ethic.

It is much further reaching than our current project or task. It becomes part of the mechanism by which we operate. Its how we interact. Its how we present solutions and spread a sense of ownership. Its how we build teams and get stakeholders working together.

Collecting feedback, analyzing risk, determining scope are all facets of our role that we bake it into our projects. Its what makes us Business Analysts, Project Managers and good at our jobs. Its second nature.

(Image referenced from Qualtrics.com)

Until recently, what I have failed to realize about myself is where my “Assumptions & Constraints” are not being considered when I write my own “System Requirements”. Where can I improve? What about me is a risk to the business? How can we neutralize that risk?

For example, a portion of me that is very nearly atrophied since college is the ability and respect needed to accommodate deadlines. What’s the solution? If we can take a look at ourselves, at our weak areas through the lense of a requirements document, we may have immediately obtained that objective view that is necessarily to address a business problem.

Looking through the Requirement Document Lenses at Ourselves:

Analyze ourselves and the situation to define the problem (the Root Cause); ask others for thier throughts too
Identify what success is going to look like (our Business Requirements) when we’re done
Outline how are we going to deliver that success story (our Functional Requirements)
Think through all the places our impact has reaches (use cases)
Add some limits and restrictions we’re likely to encounter when working through our problem (assumptions and constraints).

We could take this to a whole new level, and write out sample requirements – which I may yet do! – but it is enough to employ this objective tool that we use on our projects as a way to address our own business strategies.

How are we going to get where we need to be? What do we need to do to get there? What does success look like?

Going to be asking myself these questions for some time to come.

In the mean while, one of my own business concerns is the need to address my ability to meet deadlines. Its not as easy as it is to type it on your resume. It actually means something.

What is a deadline, really? Well, according to the Wiktionary:

deadline (plural deadlines)

A date on or before which something must be completed.

I must make this deadline or my boss will kill me!
(archaic) A guideline marked on a plate for a printing press.
(archaic) A line which doesn’t move.
(archaic) A boundary around a prison

The connotation around number 4 could prove to be a bit extreme etymologically speaking, but what does this definition tell us? Probably nothing we didn’t already know. Its a date. A date by when something is due by. Not hard, right? I pay by bills by a date, I get my car’s oil changed by a date, I go to the dentist by a date. Easy peasy.

Not so much. A deadline means so much more than how its defined. As a matter of fact, weare often the ones defining the deadlines. We define the deliverables. We define the dates. Its so much more than doing something by a date, its defining what needs done by when.

Need to ask ourselves about our deadline, to help define it for our circumstance:

What are some risk mitigation strategies for your deadlines?
Where does your deadline get communicated?
How to do you state your deadline?
How soft or hard is this deadline?
What is going to impact this deadline?
Is this deadline clear, or clear as mud?
What is expected at the end of the deadline?
How do you estimate your deadline?
When should you ask advice before giving your deadline?
When should escalate a concern about your deadline?

Communicating and escalating risks earlier is also a key component to meeting and estimating deadlines consistently.

Here is what NOT to do:

Provide a deadline in this format “I’ll have that to you sometime on Friday”;
Jump on the first distracting or more fun project thrown in front of you – any chance to do something else
Let scope creep out and destroy your project plan as that hard earned feedback rolls in;
Wait to escalate a problem until after you’ve run out of time

Here is what you could do:

Provide specific dates, and times
Communicate multiple dates – be as transparent as you can be; what is the ideal/ best case scenario? What is more likely to be delivery date? What is the worst case scenario? Express your concerns immediately.
Communicate as soon as you are aware of what will impact that will have on your plan to meet your estimated deadline
If you are unsure, ask for time to think about it, and get back with your estimate later
Include a confidence rating on how confident you are that deadline is likely to be met
Don’t be easily distracted from your original plan – escalate the question to someone who can see the bigger picture, your manager or director
“Communicating early” does not mean to wait to communicate when the deadline is slipping, it means to communicate as soon as you’ve identified something that may cause it to slip.
When the impact of an unplanned activity has equal priority, escalate the decision immediately. Don’t think you can make that call with out being the tiniest bit subjective – when we’re that close the project, we’re often too close to make the best call for the company.

It takes time to systematically approach a problem until its second nature. Thinking of deadlines, feedback and scope creep in terms of requirements feels more systematic, more error-proof, and more organized.

Good luck, and happy self-analyzing!

The Social BA - 5 Reasons to get Active Online

ccecere — Sun, 26 Aug 2012 13:32:00 GMT

Business analysts who are self-avowed social media enthusiasts will tell you that being part of a large, online community where help is only a click away is worth the time and effort. In fact, these professionals suggest that the only problem with a bit of scanning, reading, clicking, or posting on LinkedIn and Twitter every day is finding the time in a busy BA’s schedule.

Yet even the BA who is the most fanatical fan of social media admits that the endeavor has the potential to be very addictive. And upper management often looks at virtual networks with one eye on the clock and another on the purse strings. Yet most executives are coming to the realization that social sites are here to stay.

The BA Benefit of Being Online

What are the benefits to BAs who spend time on these sites? Senior Business Analyst Amirudapriya Balakumar says she has always believed that a “cumulative brain/thought process” is greater than the knowledge held by one person. She looks toward LinkedIn for enhanced knowledge and awareness. Business Analyst Peter Measures agrees, “I really enjoy having my perspective on the profession challenged on LinkedIn. It is a really useful learning tool.”

Having your professional convictions confirmed or questioned, thereby helping you grow as a BA, is a great reason to become part of an active, online community, but there are at least five additional reasons BAs should consider joining other BAs online:

1. Re-engage. One of the greatest, but often overlooked, benefits of social media for BAs is that they become re-engaged with the profession that they love. Quite simply, when you’re able to socialize with others who are performing the same work and facing the same challenges, you become re-energized. Each and every day I hear from BAs who are sharing ideas, attending classes or webinars, speaking at events or networking at meetings. Who can read these updates and not be inspired to do the same?

2. Share. There are many BAs who work as solo practitioners at small organizations and for them a virtual community can be a lifeline where they are able to brag or vent without limits. When this tweet went out, “You know you’re a BA when …” Business Analyst Sarah Entwistle tweeted back “… you have your head in your hands.” Because there are times when only another BA understands what you are going through, it’s good to know you are always able to go on LinkedIn and ask an old colleague for advice, post a question on a BA group, or shout out a quick query on Twitter. More often than not—and rather quickly—you are offered a needed template, linked to a helpful web page, sent a white paper or directed to someone who can offer more specific help.

3. Keep up. There may be no single better way to stay in tune with the latest BA trends and strategies than online and with social media. There is a constant stream of links to web pages, white papers, articles, slides, templates and other resources—and it’s usually free. Yes, it often takes some doing to work through the “spam” and get to the information you need, but diligent BAs will join the LinkedIn groups that discuss topics that interest them most, follow those on Twitter with the best information, and search on hashtags that are the most helpful. (See below for some tips.)

4. Network. The fact that social media gives you a chance to interact with other BAs is undeniable. You can easily get to know those who face the same challenges and interact with others who can offer you career advice and personal opportunities. You have the ability to ask questions of experts, voice your disagreement with the status quo and, perhaps, influence the future of your profession.

5. Find employment. Of course, social media allows you to talk with recruiters and hiring managers who are looking for professionals like you. Jobs and other opportunities are posted daily. Just ask Senior Business Analyst Debra Bambridge who is a recent convert to LinkedIn and freely admits she snagged an interview because of her online affiliation with a respected professional.

Comradery Amid Chaos

There are many groups that exist on LinkedIn and the landscape can seem chaotic. But there are ways to narrow your options and find useful discussions. The first step is to search “Business Analysis” under “Groups.” The results will show the name of each group, as well as the size and how active the group is. They’ll also tell you who in your network is a member of the group and you can further filter your search from there. Here are some popular groups to consider starting with:

IIBA (International Institute of Business Analysis) with over 35,000 members. Lots of job postings in main discussion section, but there are resources posted and some conversation.
Your local IIBA Chapter group. Some are better than others.
Business Analyst Times and ModernAnalyst.com – Business Analyst Community each have a group. Both are active.

Twitter users do not have groups to join. BAs on this site follow those who offer them the information they need—@BABOK (the official Twitter account of the International Institute of Business Analysis) and @IIBA_Boston for example—and use hashtags to further filter the content they see. You can search on any keyword preceded with a hashtag. According to a recent poll of BAs on Twitter, the following hashtags help BAs keep up with the most relevant industry posts:

· #BAOT or #baot (business analysts on twitter)

· #rqmnts (requirements) or #requirements

· #IIBA (International Institute of Business Analysis)

· #businessanalysis

· #businessanalyst (primarily for job hunters)

· #BABOK (Business Analysis Body of Knowledge)

· #CBAP (Certified Business Analysis Professional)

Cathy Cecere

Marketing Manager with Doreen Evans Associates, Inc.

http://www.doreenevans.com

Simplicity and Elegance: Expressing Your Core Competencies

James D. Murphy — Wed, 07 Mar 2012 19:48:00 GMT

Do you know what your business's core competencies are? Is there just one or are there many organizational attributes? If you answered that there are many, how would you describe them succinctly? Core competencies are one or a combination of a few unique or rare abilities; however, a description of core competencies is not simply a laundry list of various organizational attributes. It seems like a simple task, but naming your core competencies can be very difficult. This is because we, as business leaders or managers, get caught up in the tactical day-to-day tasks that we accomplish and we often mistake those tasks as our core competencies.

Years ago, when I walked to the flight line to take my first solo flight in an F-15 fighter, I was struck by an all-encompassing passion that has driven me and everyone on my team to achieve success. That passion was to define and teach the basic principles that helped me, a farm-boy from Kentucky, become one of a very few elite U.S. Air Force fighter pilots. Every individual on my team shares that passion, whether they are a fighter pilot, a U.S. Navy SEAL, a U.S. Army Ranger, Delta Force, or Special Forces operator, or one of many other classes of elite military professionals. We've built a great company. But we've done that with a clear understanding of our core competencies and organizational attributes that have guided us for years.

Defining Your Core Competencies: Examining Your Complex Organizational Attributes

Often, your true core competencies are elusive and hard to pin down, which makes defining your core competencies difficult, even when examining your organizational attributes. However, it is my belief that an expression of your true core competencies can be articulated both simply and elegantly.

Expressing core competencies is about getting to the root cause of why you do what you do and what makes you successful. A core competency is not a mission or vision statement; nor is it a statement of competitive advantage. It is not a statement of the level of quality of the products you manufacture or of the services you provide. A core competency is something more fundamental. It is both a root cause of success and an expression of the organization's unique character or reason for being. A simple and elegantly expressed core competency is a summary of what is most likely a set of complex organizational attributes.

Proof of the complexity of a core competency can be found in the way scholars in the field of business management and leadership have defined the term. In their 1990 Harvard Business Review article entitled "The Core Competence of the Corporation," C.K. Prahalad and Gary Hamel assert that an organization's core competencies can be attributed to success in a wide variety of markets, increase the perceived value to the customer, and prevent imitation by competitors. The authors conclude that these benefits are due to a "complex harmonization" of organizational attributes, creating core competencies.

How Passion Contributes to Core Competencies

Jim Collins famously characterized core competencies as "hedgehog" traits in his book "Good to Great." Instead of describing core competencies in terms of benefits, Collins describes them in terms of three dimensions - what you can be best in the world at; what drives your economic engine; and what you are deeply passionate about. Although each is important, it is often the last "dimension" that is left out of an organization's description of its organizational attributes. What you are passionate about is a core competency -- it's the fire in your belly that drives you to do every day what must be done. Without that passion, descriptions of core competencies are simply statements of what you do well, and do not include what you love. Describing the passion that drives your organization is essential to cutting through the complexity and getting to the simple and elegant truth of the organization's identity.

The science of physics provides an excellent example of simplicity and elegance. Physicists are often driven to refine their theories until they achieve an "elegant" formula. Physics is an elegant science because it seeks to find the fundamental laws of the universe. For this reason, physicists call these laws "elegant" because they are, in essence, both simple and effective.

For example, consider the famous formula E=mc². This formula simply states that energy is equal to mass times the square of the speed of light. This simple formulation was one of the most significant scientific discoveries of the past century - and it is expressed in just five symbols. Pick up any high school physics textbook and you'll find a host of simple equations that explain almost any phenomenon we encounter in the course of our everyday lives. That simple but powerful formulation is what physicists mean by "elegant."

It is essential to include the passion - your organization's "reason for being" - found within your organizational attributes, in a statement or written formulation of your organization's core competencies. Passion is a core competency that is often overlooked. Like other core competencies, passion cannot be duplicated easily. It is important, then, to expand the scope of the core competency to become more than just a statement of fundamental skill. Capture the passion and include the guiding principles - what the organization believes. Altogether, core competencies, core beliefs and the passion to do what it is that you do, come together to create the simplicity and elegance of what I call the "organizational imperative."

Organizational Imperative

Many companies do a good job of capturing the essence of their organizational imperatives by developing eloquent and inspirational mission, vision and goals statements. However, this is an awkward approach, as it usually fails the test for simplicity and elegance, and it may lack a true statement of organizational imperatives altogether.

If you correctly define your core competencies, you will realize that everything your organization accomplishes, along with its organizational attributes, should flow from and connect directly to that description. Furthermore, that definition should become a screen for every decision, however large or small, throughout the entire organization.

My company's organizational imperative is simple and elegant. It is as follows:

"To relentlessly seek to accelerate individual, team, and organizational performance through the inspiration and experience of elite military professionals. Our guiding principles are: (1) seek integrated solutions with transformative power that are simple and achieve results; (2) represent our brand - Flawless Execution; and (3) do right, speak the truth, and demonstrate excellence."

In just 50 words, we have described our passion, our core competencies, our organizational attributes and our beliefs.

Like an elegant formula in physics, a complete and concise organizational imperative describes your organization's behavior. It is the standard to which all actions are executed and decisions are measured and made.

About the Author

James D. Murphy

Founder and CEO of Afterburner, Inc.

Executive Coaching and Debriefing for Corporate Leadership Development Programs

James D. Murphy — Mon, 19 Dec 2011 19:53:00 GMT

In today's management environment, new forms of and tools for corporate leadership development programs have emerged. One of the most popular development tools is executive coaching. The number of executive coaches has more than doubled in the past decade and corporate leadership development programs are utilizing their services more frequently. However, the fundamentals of executive coaching have actually been around for many years in the form of debriefing.

In the U.S. Air Force, debriefing after every flight was an essential process in my training and development as an F-15 fighter pilot. My instructor pilot debriefed with me after every training flight. Later, when I became an instructor pilot and squadron training officer, I did the same with my young pilots. After leaving the Air Force, I used the basic tenets of the debriefing process I had learned, adapted the process to a sales force I led in a civilian company, and further refined that process over the next 16 years.

I was recently reminded just how broadly applicable the debriefing framework is as an executive coaching tool when a professor approached me at the end of a lecture to a healthcare team, thanking me for explaining the process of debriefing to the team. She told me, "You've given me the means to have a difficult conversation with a student, allowing her see what, in herself, needs to change in order for her to be successful."

Corporate leadership development programs require both executive coaching and debriefing practices, processes that utilize complex discussions and deep analyses that resist oversimplification. Executive coaches help their clients to see themselves more accurately, allowing clients to establish actionable objectives for personal change. Likewise, debriefing helps individuals and teams more accurately analyze the work that they have done in order to make efforts to improve upon their past initiatives. While executive coaching focuses upon the individual, proper debriefing is effective in both individual and team development. The principles are the same, but for the debriefing process, the approach is more direct, objective, and simple.

Differences Between Executive Coaching and Debriefing Practices

Although corporate leadership development programs draw from both executive coaching and debriefing practices, there is a significant difference between the two processes: First, executive coaching practices struggle to get to the actionable objectives for change. This is where the highly subjective talent and skill of the coach comes in to play. Second, coaching is less process-driven than proper debriefing. Successful executive coaching is dependent upon the individual style and skill of the coach and the character traits of their client. Successful debriefing, however, is driven by a repeatable, structured process.

Let us examine some of the elements of a good debriefing process and compare them to an executive coaching practice. The first of those elements is what we call "tone." In the debriefing practice, setting the right tone is critical. The right tone is nameless and rankless, which gives everyone an equal footing. Amy Edmondson, Novartis Professor of Leadership and Management at Harvard Business School, has labeled such a tone "psychologically safe." In executive coaching, a coach will take care to establish a trusting and psychologically safe tone much like a professional therapist or physician would for a patient. This tone is essential in order to achieve the honesty and truthfulness necessary to identify objectives for change. In debriefing, the proper tone is critical to uncovering mistakes and isolating successes.

Corporate leadership development programs also require the correct tone. With the right tone, debriefing and executive coaching practices can enable teams and individuals to find the truth. In the executive coaching practice, obtaining the truth of how others see or perceive the client can be a tough process, which is typical of the analysis of any complex issue. This is the same in the debriefing practice. Whether we're debriefing a team or an individual's performance, we have to be prepared to dig deep into the root causes of both successes and errors. In order to do this, we only use the debriefing practice for clear and measurable objectives. One cannot debrief in any truly successful and meaningful way without specific and quantifiable objectives.

Utilizing Clear and Measurable Objectives

In our corporate leadership development programs, we emphasize the importance of stating clear objectives in both executive coaching and debriefing practices. Clear objectives allow the debriefing process to take two procedural steps in order to discover the root causes. First, we take a look at how well we executed toward our stated objectives - did we do what we said we were going to do? Did we execute this process in the way that we said we were going to do it? Take a look at each of the tasks we had to perform in order to meet our objective(s). Was each of these steps effective? From this inquisitive process, we are able to create a short list of successes and errors that form the basis of our next step: analyzing the execution.

We analyze the execution by taking each of our results – the successes and errors – and subject each to a series of "why's" until we get to the root cause. We continually ask "why" until we get to the fundamental root cause: Why did that happen? What really failed? Did we just get lucky? We can't fix something, replicate a success, identify a near miss, or address a personal shortcoming until we know exactly what needs to change and why.

The Importance of Actionable Feedback

As soon as we know what that root cause is, we can get to the real point of debriefing and executive coaching - taking corrective action. We need actionable feedback in order to improve ourselves. Corporate leadership development programs help to continuously improve teams and organizations by requiring actionable feedback. Research demonstrates that feedback that is not actionable can actually result in negative behaviors. The product of debriefing and executive coaching must focus upon what can be done to address the root causes. Without a specific course of action, reflective activities will be a waste of time at best, and can potentially trigger negative behaviors at worst.

An effective debriefing process develops an actionable lesson learned that addresses each of the identified results - each success or error. A lesson learned is a set of steps intended to resolve the error or replicate the success of each of the root causes. It is an objective and clear set of instructions or actions necessary to improve personal, team and organizational performance in the future. Furthermore, in the context of team debriefing, it assigns a single accountable individual to take that set of actions or to properly store the learning for future use.

Such are the basic processes, utilized by corporate leadership development programs, for both debriefing and executive coaching. However, there is one final secret to successfully using these practices. In our corporate leadership development programs, we recommend performing these processes frequently and in small, achievable portions. Successful executive coaches help clients to tackle personal goals a little at a time, meeting with individuals to assess incremental progress relatively frequently, typically every two weeks. The debriefing frequency should also follow this timeline. If debriefing occurs less frequently than once per month, the individual or the team is likely to "choke on the elephant." It is hard to change, especially when you are attempting a great amount of change in a short period of time. Aim to change slowly, a little at a time. This is the same philosophy behind successful change methodologies.

Conclusion

There is a deep, meaningful correlation between the debriefing and executive coaching processes. James Hunt and Joseph Weintraub, Babson College of Management professors, argue that facilitated learning, such as executive coaching, is leveraged to extraordinary results through forms including the U.S. Army's After Action Review (AAR) and the U.S. Air Force's debriefing process. Both executive coaching and debriefing are forms of facilitated learning, and both are utilized in successful corporate leadership development programs. However, in executive coaching, a third party facilitates the learning for one member of an organization. But the debriefing process allows the team to facilitate learning for individual team members and the organization as a whole.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

A dressing down for business analysts

Robin Grace — Tue, 12 Jul 2011 08:58:00 GMT

BA: “They didn’t pitch for my workshop. Again.”

Mentor: “You must be mortified.”

BA: “Seriously, they come up with these lame excuses: they don’t understand that computer stuff, they’re too busy, they think it’s a waste of time. One even told me to get it done and let him have a look when I’m finished. How the hell must I fathom the requirements myself? And they call that idiot a professional.”

Mentor: “You sound like a stuck record. Every other week you stomp in here ranting about the users, the stakeholders, the so-called professionals who waste your time. You always blame everybody else.”

BA: “So now it’s my fault?”

Mentor: “When I was a green analyst I had the same problem. You know what I did?”

BA: “Hired Chuck Norris?”

Mentor: “I went back to basics – I started planning properly.”

BA: “Planning? First it’s my fault and now I never planned! Well I did plan. I planned for all those morons to pitch at my meeting this morning – I even bought muffins, for goodness’ sake – and none of them arrived. By the way – you want a muffin?”

Music to a BA’s ears

If I had R100 for every time I heard a BA complain about the stakeholders not pitching to their meetings I would have – and I am not making this up – exactly R87 bazillion and 50 cents. The big problem with people not pitching to your meetings is that by the time you see a room full of empty seats it’s too late. The damage is done. You see, getting stakeholders to your meetings starts long before you even call a meeting.

In fact, it begins with a classic film: “The Sound of Music”. “When you read you begin with A, B, C. When you sing you begin with Do-Re-Mi.” And then you have the lines, “Doe, a deer, a female deer,” and so on. The point is that you begin at the beginning and the beginning of any BA project is planning.

So, as my fictitious friend asked earlier: What does planning have to do with putting bums on boardroom seats? For starters most BAs I come across don’t do any planning, yet the Business Analyst Body of Knowledge (BABOK) clearly has an entire chapter devoted to it – Chapter 2 to be precise. Some of you may argue that you do plan. You create lists of stakeholders, you assign roles and responsibilities. But, on closer inspection, most BAs think that copying and pasting a list of stakeholders from some other project is a substitute for planning. It isn’t. There is no way around it. If you copied and pasted then you did not plan.

The list is important because it is the very first step the BA, that’s you, takes in understanding who does what, when, how, where and why. And if you don’t know that then you cannot convey any sense of understanding, relevance, or importance to the stakeholders. And without those only the soft-hearted will attend your meetings.

The BA communications plan describes how we will communicate with the stakeholders. Any stakeholders on the list that have an RACI “C” next to their name must become part of the elicitation process. Most often we will “C”onsult with them in a requirements workshop. We have to inform them of when we would like to “C”onsult with them and exactly what we will need from them.

It all makes perfectly good sense because you are ensuring that the right people are involved and that they know what is expected of them. The next thing you do is get their consent, their approval, because that leads to buy-in. You’ll need them to agree to what must be done, when it must be done, and who must perform each activity to gather all the requirements. There is also an implied contract that the BA needs those people to do their work for the sponsor and, if they don’t pitch, they are wasting the sponsor’s money. One way of getting that message across is through the invitation to the workshop. Suggest that the participant’s involvement is crucial to the success of the project and that the sponsor is aware of this. If the sponsor has any organisational clout, it’s the added incentive stakeholders need to be there and be on time. In other words: wag the big stick.

The BA and the TP

What you’ve done by ensuring only the right people attend the meeting is that nobody’s time is wasted. You don’t have people sitting around wondering why they never said a thing, never contributed one jot to the proceedings. That quickly annoys people, particularly the busy ones, normally the ones important to the project at some point, if not right then. Having only the right people at meetings also makes the meetings move along more swiftly. Shorter meetings leave people more inclined to attend others. More focused meetings, because you have only the necessary people there, also finish more quickly because everyone is driving at the same clear goal. So where do you find the required participants? You go back to your stakeholder list and communications plan, which should identify who should be present for the process under scrutiny and it’ll be correct because you didn’t just copy and paste.

The next item on your busy agenda is language. Imagine the conversation at the beginning of this story being between a BA speaking Russian and the mentor speaking Cantonese. They’re probably going to get things a little muddled and may even end up throttling one another. By the same token you need to speak the language your stakeholders understand. If every other word you use is a TLA or jargon that only BAs get, then your stakeholders will quickly get bored and start imagining the fantastic little getaway they’ve arranged for the weekend. Or you, on the loo.

Pants around your ankles or TP in your hand, context is king. Put the meeting in the context of your stakeholders so that they can get the reasons why they are there in the first place: “I know you have customers and they place orders; tell me more about what you do when you receive a customer order.” It focuses the workshop immediately, the participants feel you understand what they do, and it shows you value their time enough to do some groundwork.

If you do all of this stuff – not the loo bit – through careful up-front planning to get a focused, contextualised outcome then stakeholders will quickly feel appreciated and relevant and possibly even enthusiastic about your meetings. OK, maybe not enthusiastic. But you will be able to imagine a completely different conversation to the one that opened this story.

I always say: If you can show business real value in what you do then business will start to really value you.

Robin Grace

Principal business analysis consultant at IndigoCube

Complexity: The Execution Challenge You Don't See

James D. Murphy — Mon, 18 Apr 2011 21:00:00 GMT

When you think of the word 'complex', do you ever think about what it has to do with project execution? Ask a management consulting firm to define 'complex' and you'll get a response like "well, it's a concept that can affect your life, your family, your team and your organization." That's because consultants understand that complexity lies in every aspect of strategic planning, whether at home or in the workplace, and that complexity is a concept that needs to be clearly understood in order to anticipate and overcome execution challenges.

The Oxford English Dictionary has three separate entries for the word 'complex'. But in general use it is defined as: intricate, not easily analyzed or disentangled. We live in a highly complex world and while we have a general understanding of the complexity with which we approach execution challenges, for the most part, our human brains are not wired to comprehend the intricate concepts needed for strategic planning. But with outside management consulting, companies often see that it is easier to understand the complex architecture of cause and effect.

Simplicity vs. Complexity

From our day-to-day perspective, simple and complicated things are things we create or conceive. A knife is simple. A bicycle is relatively simple. We can look at all its parts and see how it operates. You might need to understand some basic physics to understand how a bicycle's gear shift works, but that is a relatively simple concept for humans to grasp. But when it comes to comprehending the inner workings of strategic planning and its role in execution, these become complexities that are difficult to grasp - a fact that management consulting firms are well aware of.

We know that manufacturing processes are complicated, and even bureaucratic processes are complicated. And just consider how complicated legal processes are. But we also know that none of these simple or complicated things creates anything greater than itself. The whole of an outcome realized through strategic planning is only equal to the sum of its parts. Without a rider, the bicycle is just an organized set of parts. Without litigation and judgment, legal execution and the enactment of laws are nothing more than ink on a page. Management consulting firms understand that human systems create something greater than their individual components. Consider the global economy - it appears to be just billions of individual people toiling away in some haphazard manner. But that global economy, as wildly unpredictable as it may be, is a complex system, reliant upon consistent execution achieved by strategic planning through a number of human variables.

When we were taught history in school, most of us probably saw human history as a sequence of causes and effects. But the world is not like a line of dominoes in which one topples to cause another to topple, then another and then another - instead, the real world is non-linear. By that we mean that the chain of cause and effect feeds back upon itself to perpetuate more change. When educating clients about complexity, management consulting firms understand that foreseeing the ultimate execution of such non-linear cause and effect interactions within strategic planning is either impossible or simply exceeds our human capacity to comprehend. Every cause is the sum of countless effects and every effect is the sum of countless causes. Cause and effect become indistinguishable from one another. We must relinquish our linear view of the world and embrace its complex wholeness. We must view the world as a complex interdependent system.

If it weren't for complexity, all our challenges and strategic planning problems could be reduced to manageable and highly predictable processes that we could shape to achieve the execution we desire. But complexity is an integral aspect of life itself - a concept that management consulting firms impart to help corporate clients understand how to approach complexity in the workplace.

Complexity Directly Affects Business Leaders

IBM conducted a survey of over 1,500 global CEOs and other leaders and in 2010, and produced a report entitled Capitalizing on Complexity in which the first of its four primary findings identified the following: "Today's complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it (1)." Leaders often identify complexity as such an issue in execution, but businesses can leverage a management consulting firm to manage the intricacies of strategic planning to embrace and manage complexity.

Peter Senge, in his groundbreaking management book The Fifth Discipline, challenges us to see the world as a whole, to see the "subtle interconnectedness that gives living systems their unique character (2)." He challenges us to see our world, and our business execution, as part of systems and as systems themselves. The interplay of cause and effect in strategic planning is dizzying and in our limited comprehension, appears chaotic and has far-ranging consequences. Managing complexity, though difficult, is not impossible (at least in the short term) and management consulting firms teach clients how to prepare for unpredictable environments. At best, we can only anticipate change, plan for it, and respond wisely when it surprises us.

The Rate of Change is Increasing

If the science of complexity teaches us one thing, it is that our human world will always remain unpredictable. As the level of complexity continues to increase, the rate of change increases - making managing strategic planning to achieve execution more difficult. It is this speed of change that both confounds and excites organizations all over the world, and prompts companies to seek management consulting to build a forward-looking strategy. It confounds because only highly energetic and creative organizations can keep up with the pace of change. It is exhausting and worrisome. But constant and rapid change also means that there are more and more opportunities available to those ready to seize them and take action.

And yet, it's astounding how people tend to think that management consulting concepts and strategic planning are linear processes. The array of business publications available on bookshelves today demonstrates this thirst for linear execution and computable certainty. It's as if the majority of people believe that there is some mystical set of rules that, if we knew them, would guarantee success. But, there can be no single process or set of rules that can guarantee anything in complex systems. However, management consulting firms can equip companies with a set of process tools and principles that enable successful adaptation within unpredictable complex systems.

Management consulting companies teach simple holistic process to help us harness strategic planning in order to achieve execution within these modern, rapidly changing, globally-connected systems. One of the most important things to realize is that we and the organizations we form are constantly interacting with other complex systems. Complex systems are ubiquitous. And as far as decision-making and problem-solving is concerned, this simple fact tends to cause some very serious planning problems.

Conclusion

Surviving and thriving in a world increasingly dominated by the capricious effects of interacting complex systems requires rapid adaptability - a concept that management consulting firms have embraced, and teach to companies to help them achieve execution through strategic planning. We are all perpetually engaged in a fight with disruptive, unpredictable change. The organization that can most rapidly anticipate, process, and adapt to that change wins the battle of maneuvers. Call it what you will - maneuverability, adaptability, or agility - winning requires a fundamental understanding of the effects of interactions within and between complex systems in our companies and organizations to achieve success.

Works Cited

1. Capitalizing on Complexity. IBM Corporation 2010. Pg 8.

2. Peter Senge, The Fifth Discipline: The Art and Practice of the Learning Organization. 2006 pg. 69.

About the Author

As the founder and CEO of Afterburner, Inc., James D. Murphy has a unique, powerful mix of leadership skills in both the military and business worlds. After graduating from the University of Kentucky, Murphy joined the U.S. Air Force where he learned to fly the F-15, logging over 1,200 hours as an instructor pilot in the F-15 and accumulating over 3,200 hours of flight time in other high-performance jet aircraft. He has also flown missions to Central America, Asia, Central Europe and the Middle East. As Afterburner's leadership keynote speaker, Murphy has helped top business leaders transform strategy into action by showing that the concepts of the Flawless Execution(SM) model could be applied to business process improvement and engaging the proven model - "Plan. Brief. Execute. Debrief." Murphy has been regularly featured in such publications as The Wall Street Journal, BusinessWeek, and Newsweek, and has appeared on CNN, Fox News, and Bloomberg News to name a few. For more information on Afterburner, Inc., please visit www.afterburner.com.

BA Careers - Is industry experience more important than Analytical skill?

HSantanam — Mon, 06 Dec 2010 19:32:00 GMT

Business Analysts often delve into business requirements, gathering, understanding and documenting business processes and functions. An analytical mind and detailed information gathering are considered to be essential; one wonders though, if industry experience is a must for good business analysis skills. After all, if you knew well the ins and outs of the industry you were in, that’s good, right? The answer is probably, but not always. Why is that?

Business analysts, like developers and solution architects, are trained to think logically and focus on specific issues at hand. Once in a while, though, they need to step back, and like a painter evaluating and assessing his painting-in-progress, assess their progress on the task at hand and be prepared to explain it to a wider audience in plain talk. That, in my opinion, is an essential skill of the modern analyst.

First, industry experience means less time is wasted knowing the industry environment – the general models the business follows, what regulatory and competitive arena it is part of and some common terminology. Secondly, business process flows are easier to understand, say, if one was documenting business process flows for a financial transaction, if that person had already worked in a financial services firm in a financial transaction environment (e.g., Front office, where the deals were made, or the middle office, where financial and regulatory processes were checked or filtered, and the back office, where the transactions were processed and settled – and where exceptions were followed up for closure).

That of course, brings up an interesting question – if a business analyst goes into an unfamiliar environment, how much time should be spent learning the business environment? Wouldn’t that leave less time for focusing on the essentials of requirements, elicitations and documentation? And how valuable would all that be, anyway? After all, time is money – and with workloads being what they these days, such knowledge, while good for a progressive and open mind, would be quite expensive indeed, wouldn’t it?

The answer is that depending on the timeframe, it would be beneficial to get the most important work done first, which would mean skipping the overview on the business. In a limited time frame, a “bullet-point” information dissemination method (summary) might work. Asking questions in the right environment is healthy, but learning important concepts on one’s own time is a better idea. After all, stakeholders have limited time available even for requirements – they might not have the patience for an extended basics class. On the other hand, workflows and the reasoning behind them should be questioned to extract the maximum value for optimization and better business.

What about the times when it might be beneficial to hire a business analyst who is sharp and curious, but not industry-knowledgeable? When the existing patterns are so constricted and “inside the box” that a fresh perspective is needed, hiring analysts without a lot of presumptions and insider’s knowledge is actually a good idea.

I worked in a firm once where I was asked to interview, evaluate and recommend IT candidates (mostly developers, some analysts). At the end of the face-to-face interview, I would ask the candidate to solve a problem on pen and paper. The rules were clear – no writing code, simply writing out the solutions – a diagram was acceptable as long as it wasn’t too complex. Additionally, the answer had to be limited to 1 page and be completed in about 30 minutes. I was amazed at how the smartest candidates failed this written “test” – it was actually quite simple, for it did not require deep industry knowledge and did not put the candidate on the spot by testing coding knowledge. I simply wanted to know how the candidate thought about solving problems and whether he/she was able to put it on paper. I often got several pages of answers, written code and requests for extending the time available, though all the requirements for the written test were explained before hand. Needless to say, these candidates were not hired.

Career Possibilities for Business Analysts-expanding your horizons

HSantanam — Wed, 17 Nov 2010 16:55:00 GMT

You have achieved your short term BA goals. You want to expand your horizons and see what else is out there and how you can progress in your career and gain knowledge and keep your career up-to-date as well. What are some of the possibilities out there that won't force you to re-learn something new from scratch? Some possibilities for career and knowledge expansion in areas related (or of possible interest) to Business Analysis:

Project Management: The PMP (Project Management Professional) certification from the Project Management Institute (www.pmi.org) is valued by many employers. Business Analysts, I believe, are well-suited for project management, which aims for successful completion of projects from inception to closing, while managing (juggling?) competing constraints of time, cost and scope. The PMBOK (Project Management Body of Knowledge), which is similar to BABOK, is a framework used in implementation of best project practices regardless of industry or project scope. The concepts used in PMBOK would be familiar to anyone who knows BABOK - for example, processes in the knowledge areas have inputs, tools and techniques and outputs. The PMP certification is valid for 3 years and may be renewed by obtaining training or other credits known as PDUs.

Information Systems Security: The Certified Information Systems Security Professional (CISSP) certification from the International Information Systems Security Certification Consortium Inc - "ISC2" for short (https://www.isc2.org/) - is also in demand for professionals catering to security related aspects of Information Technology - from IT systems architects to developers to Audit, Compliance and Risk managers. The CISSP Common Body of Knowledge (CBK) covers 10 domains - Information Security Governance, Security Architecture and Design, Cryptography, Physical Security, Access Controls, Applications Development Security, Legal-Regulations-Compliance and Investigations, Business Continuity and Disaster Recovery Planning, Operations Security. The aim is to instill a comprehensive overview of the various aspects of the IT environment and how they all relate to security and best practices. Like the PMP, the credentials need to be renewed every three years through training, volunteering in ISC2 programs or other related knowledge.

Some other certifications from ISC2 that may be of interest:

Certified Secure Software Lifecycle Professional (CSSLP) (https://www.isc2.org/csslp/default.aspx) : As the name implies, the certification is for those involved in the software lifecycle and is concerned with building security into the entire Software Development Life Cycle. It deals with secure software knowledge in the design, implementation/coding, testing, acceptance, deployment, operations, maintenance and disposal domains.

Systems Security Certified Practitioner (SSCP) (https://www.isc2.org/sscp/default.aspx): According to ISC2, this title is good for Network Security Engineers, Security Systems Analysts and Security Administrators. So Business Analysts who want to learn more about the security area and become experts may consider this.

The CISSP certification can also be obtained, in addition to the general CISSP described above, in specializations ("concentrations") below:

Pasted from <https://www.isc2.org/concentrations/default.aspx>

Other certifications currently in demand include:

ITIL (http://www.itil-officialsite.com/home/home.asp) - (Information Technology Infrastructure Library) which is a set of concepts and practices for Information Technology Services Management. It deals with management , delivery and support of IT services to business - which would be ideal, for say, managing a hosting area, data center, software as a service, change management and well..you get the idea.

Certified Information Systems Auditor (CISA) from ISACA (originally Information Systems Audit and Control Association, now known by its acronym only)

For Business Analysts who think they have a knack for probing IT systems and ensuring that process conform to policies and want to pursue an IT audit/Compliance career, the CISA might be a good bet.

Other certifications from ISACA in a similar vein include:

Certified Information Security Manager (CISM) - for those who design, build or manage IT security programs.
Certified in the Governance of Enterprise IT (CGEIT) - for those involved in IT governance.
Certified in Risk and Information Systems Control (CRISC) - for those involved with risk assessment/evaluation/monitoring/response etc.

Information on the above certifications can be found here: http://www.isaca.org/CERTIFICATION/Pages/default.aspx

There are many other paths to expand one's career horizons, depending on interest, time and inclination - Solutions Architects, Enterprise Architects, Database analysts and Network specialists are only a few - business analysts, due to the detailed nature of their work, are well positioned to transition or acquire new skill sets.

The emerging field of Wireless application specialists - mobile apps, application security (wireless protocols, app security design etc) is also lucrative. As mobile technology and gadgets (smart phones, tablets etc) get more mature, more business functions will add on mobile functionality.

If there are other interesting accreditations, certifications or knowledge programs that I have missed, I would love to hear about it…Thanks

HS.

Enter the Business Engineer

Mendix.com — Tue, 05 Oct 2010 13:53:00 GMT

At Mendix, we find that our customers appoint a particular kind of person to work with our products. Sometimes they’re from IT, sometimes they’re a business analyst or project manager – in any case, they practice the skills of both fields. Times are changing, departmental lines are blurring, and a new breed of business superhero has risen: the BE.

The ‘Business Engineer’ – who are they, what do they do, and why you want to know them.

Who

Until now, these men and women of myth have appeared under the guise of your organizational boundaries – half business and half IT. As champions of business modeling, they dance between the ranks of geeks and suits in companies everywhere, aptly increasing business agility at every collaborative junction. With a flash drive dangling from their sports car keychain and first place positions in both Online Poker and Fantasy Baseball, they are what we believe to be the future of the modern business analyst. In this series of blog posts, we attempt to uncover the true nature of this evolved employee…

What

The title of ‘business engineer’ is not completely novel, as it has been used in the past to describe a role similar to that of a business development manager. Under a new light of enterprise software modeling, this term refers to the business analyst on technical steroids – or the IT whiz with a knack for client relations. These skills, once segregated at a basic level of undergraduate education, have merged into a hybrid force of human capital with more creative power than either part could ever fathom.

These collaborative powers can push companies into unchartered profits, as they attribute to the resiliency of a company’s technology. Agility, as readers of this blog know, affords an organization the ability to change with its business environment. The more easily technological change can occur, the faster and more decisive an organization becomes. Charles Darwin says it best: “In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed.”

The business engineer is not a mythical entity – they may even be sitting in the room as you read this post. Finding them and harnessing their abilities should be a primary goal of any manager. In terms of organizational behavior, they are the ‘central connector.’ In terms of organizational culture, they are the ‘go-to guy.’ And in terms of business agility, they are the binding force between business users and technical experts that have never been able to see eye to eye.

Why

The reasons why you’d want business engineers in your company are significant. They make the technology that your company uses easier to use, more intuitive, and they do so faster and with minimal adversity. With the adoption of visual business modeling, and agile development methodologies, these unsung heroes of the enterprise era are here to stay. Do you know the business engineer at your organization? If not, it just might be you.

Being New 101

Seilevel — Thu, 26 Aug 2010 19:04:00 GMT

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

http://requirements.seilevel.com/blog/

IT Black Ops

Seilevel — Sun, 22 Aug 2010 23:26:00 GMT

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team. A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well. However, unless you are at an executive level, there is very little you can do to shut down the black ops team. In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built. Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence. However, once their presence is detected, a project and budgetary train wreck usually ensues.

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place. It’s probably because of one or more of the following reasons:

1.Low confidence that IT will be able to build something that actually solves a business problem. Sometimes this low confidence is warranted.

2.No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it).

3.Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it.

Lack of understanding about why it takes so long to develop working software.
Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1.Keep the business engaged throughout the development lifecycle. Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.

2.Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution. Giving the business ownership of the process will help.

3.Each project should have a clear ROI. This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…” People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem. Just watch out for pencil-whipped and contrived ROIs. Be suspicious of any feature which does not tie back to a quantifiable business objective.

4.Use comparable projects to set expectations. People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be. This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”. In order to head this off, it helps to show the budget, resources, and time to execute for similar projects. It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?” You can use the lessons learned on other projects to help answer this question.
It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true. Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

By Jhulgan

Want more? Check out our other posts here.

Building Credibility With Your Team

Seilevel — Wed, 28 Jul 2010 22:07:00 GMT

As consultants and product managers, it is important that we quickly build and maintain credibility with our team so that we can work productively and effectively. If you are unable to join the team dynamics, the work that we provide will be met with apathy or even outright hostility. I’ve learned a few tips to help establish credibility quickly.

Maintain your visibility – Initially, it is important to get plugged into as many face-to-face meetings and conversations as possible. By being face-to-face it gives you the availability to learn more about the project right away, gives you context, and you will quickly meet many of the people who might influence your efforts. Your team can see you demonstrating your expertise and learning about the challenges of the project. They will see you as a member of the group. If you are not able to join many meetings, just being onsite and visible will help establish your presence.

Learn about your customer and your team - Knowing the business issues and pain points of the project team will help establish your credibility. Research the business and the challenges before meeting with your team. Usually, you will have a point of contact within the organization who can share the current challenges, and possibly some of the team dynamics. It’s also important to keep an open mind when learning about a new group. Everyone has a perspective and until you can gather your own impressions, take what’s shared with you with a grain of salt.

Be Personable – It is critical to try to establish a personal relationship beyond the necessary professional one. I’ve found that if a new team member can connect with me on a personal level; it goes a long way towards smoothing out the edges professionally. Try to ask your team members about appropriate things that matter to them, like kids, interests or holiday plans. If you do ask, be sure to remember what they told you and be genuinely interested. If you do ask about a team member’s personal interests – Don’t forget the answers. Even if you have to jot them down on a notepad to remember later. It’s critical that you not ask the same personal question twice. People may give you a pass if you repeatedly ask the same question about work related topics, but if they care enough to give you an answer about something personal, you should care enough to remember it.

Be a good communicator and listener – The ability to communicate effectively and sincerely will always enhance your ability to establish credibility. It’s important to be engaging, and build professional relationships. Effective communication can quickly build a personal rapport between you and the other team members.

Never let ‘em see you sweat-

This is hard to do in practice but important. If a person is going to have faith or confidence in your ability to get the job done, then you should have faith in yourself. Issues and problems will come up from time to time, but having grace under pressure allows people to feel comfortable that you are the part of the solution and not part of the problem.

Do you have tips on how to build credibility with your team? Do you want to check out other blogs?

You can check us out here.

By Landerson

BA World Sydney - A review

Craig Brown — Tue, 27 Jul 2010 00:31:00 GMT

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event. On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

(Also posted at www.BetterProjects.net)

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Seilevel — Thu, 10 Jun 2010 13:52:00 GMT

By Jhulgan

I used to dread hearing the question, “So what do you do for a living?” This was often usually asked by a family member or other acquaintances not familiar with the software development lifecycle, IT, or business processes in general. For business analysts, product managers, and other software requirements types, it’s difficult to give an answer without being convoluted or sounding like Tom Smykowski:

This great post expresses a similar insight beautifully, but many of us struggle with good, one-sentence responses to what it is we do everyday in simple English. I thought I would plagiarize some ideas that I’ve heard from colleagues over the years and compile them here:

“We help businesses figure out what software they need to build to solve business problems.” This is a personal favorite of mine that I stole from Marc (who posts under mtalbot on this here blog). It’s especially relevant to IT consultants/contractors. Just about everyone knows what software is, and a lot of people understand that just about every business runs on some sort of software to solve business problems.
“We help communicate the business needs of a system in a language software developers understand.” A variation of this is, “We translate from business to geek”, although I am less fond of the second version because it veers into Smykowski land.
“We make sure the right software is being developed at the right time, for the right people.” The emphasis here is on the right software. This response is nice because it allows you to segue adeptly into a discussion about business objectives.
“We help the business get the most value out of their development dollar.” This response stresses the fact that you are not just a scribe or secretary writing things down, formatting them, and delivering them to the development staff. You are helping make the tough decisions on which features to cut and which bugs to fix, and quantifying those decisions in terms of dollars and cents.
“We work with the business to find the appropriate scope of a software development project and ensure that what is built is what the business expects.” Whenever I am asked the dreaded WDYDFAL question, this is what almost immediately comes to mind. Sometimes I fill in the details of working with pictures to help model current business processes (and desired business processes).

So how about all of our readers? What answers have you come up with? Do you dodge this question altogether, or do you sound like a fumbling Smykowski? Hopefully we can all help each other find good answers to this question. After all, you never know when you’ll be in a meeting with “The Bobs” and the pressure will be on!

You can check out our other blog posts here

Tips for managing business meetings

georgiamotoc — Sun, 27 Sep 2009 17:41:00 GMT

The tips below are things I've learned the hard way and I think they're going to help you, especially if you're new in the BA field.

You don't have to take things too seriously, don't be too harsh on yourself and others. There will always be people who criticize you but also those who understand you. Learning how to talk to users, how to manage their questions, how to be a good BA takes time.

First of all: Believe in yourself and your ability to handle any situation that might arise in the meeting. Think about something nice and positive. Don’t worry about failing.

Be on time. In some companies, there’s a tacit agreement that you should always go to a meeting a few minutes late. Even being 5 minutes late can be annoying to some people (…after 5 minutes I start to ask myself if I’m in the wrong room).

Be prepared. If you meet to review your document, send the document out prior the meeting and let people know if they should print their copy or you will print for them. Always print extra copies because one person for sure will come without printing or has printed the wrong version.

Be dressed for success. People look at how you dress. Besides, good clothes make you look and feel better.

Open your eyes and watch the non-verbal behavior. Be observant.

Pay attention to what is said.

Take lots of notes.

Have scrap paper with you in case the user does not understand what you’re saying; draw it for him/her. Especially if English is your second language you may have trouble clearly stating your question, so drawing helps.

Be open – sometimes we’re so into what we think that we’re not listening to what the other person is saying. Be open to suggestions, comments, even criticism.

Ask for clarifications - Users explain a function assuming that you know what they are talking about. I think this is the biggest challenge of all – if you’re not familiar with the business, it can take months until you understand what the users are talking about. But try to find out about the business on your own as much as you can, either from the internet or colleagues; at least you go to the meeting with some basic questions answered and you don’t make a total fool of yourself.

Don’t hesitate. Don’t use fillers such as “Uhhmmm…” – that just doesn’t make you look too sure of what you’re saying.

Instead of saying “I don’t know”, say “To my understanding” or “To my knowledge….” Then state what you do know about that subject.

Stick to the questions you sent to the user in advance (assuming you did that), unless the discussion leads you to other questions that are related.

Keep the meeting focused on the subject. I know it’s hard; especially when more than two people are in the meeting, each one has opinions and makes statements. It takes some good facilitating skills to bring them back on track.

If you need to talk to two different users about the same function, try to bring them in the same room instead of talking to them one by one – it will save you some back and forth and they can agree to what is said right there.

Don’t take anything personally, even if it’s personal. You are in the meeting to gather and talk requirements, nothing more.

Most importantly - Relax. Smile. Be friendly.

Do you have any tips to share? We all started somewhere and experiences vary. What was your experience from attending meetings?

Video: Get things done with Autofocus

Craig Brown — Mon, 20 Jul 2009 13:29:00 GMT

This video offers a great way to manage your task list. Check it out and consider how it can help you stay on top of your work.

When a business case is not a business case

Ed Taaffe — Tue, 14 Jul 2009 12:13:00 GMT

When it establishes that there is no case for the proposed initiative.
When it fails to identify and present the benefits of the propsal sufficiently well to win support.
Both of these situations have the same result only the second one is a lost opportunity for the business.

You can talk to five different people who have that word in their CV and each one will probably have a different take on what a business case is for, who should prepare it and what it should contain.
In fact, you could say that the whole science around business cases, especially those involving IT investment has moved on substantially in the past two or three years.

Many of the concept of benefits were rarely discussed ten years ago, let alone benefits realisation. Today all that has changed. Some examples of the importance this subject has achieved is the Cranfield university Benefits Dependency Network Tool and more recently the Microsoft REJ framework.
Here is a simple explanation that takes into account more recent developments in thinking and puts a simple framework around what a business case is and is not.
1. A business case must live up to billing and make a case for the proposed project. That means demonstrating how the project will deliver benefits for the business
2. A business case should take three forms,
a. Initially it should be an outline business case. This is a non detailed and very tacit explanation of why some very knowledgeable stakeholders feel that this is a very good idea.
b. A full blown business case with detailed cost benefit analysis and detailed financial calculations such as ROI, EVA, IRR,NPV etc
c. A one page summary of the final business case for people with little time for detail.
3. A business case must take a analytic view and not be an excuse to purchase my new toy, hence it should examine tactical solutions and doing nothing.
4. A business case should take into account political ,economic, sociologic and technologic trends likely to impact on the projects ability to deliver
5. It should take account of the organisations ability to deliver the project and realise the benefits.
6. The business case should always be a living document that is carefully managed by someone who carries a key responsibility for the project.

The diagram above shows a simple process for producing and managing a business case.
The top section represents the activities that generally occur prior to going into the implementation phase of the project .
The bottom section represents the activities that continue during and after implementation.
The first priority is to expand a little on the initial concept and capture high level requirements. In dong this it will be key to get an understanding of the benefits hoped for by stakeholders and to abstract form them the knowledge and experience that has lead them to this conclusion and the assumptions that are underpinning it.
Next a high level examination of the potential solutions, include the ones that are likely to be already suggested, a do nothing scenario and a tactical solution.
From here an outline business case can quickly be created that encapsulates all the motivations, expectations and tacit understanding of the problem and potential solutions and provides a building block for stakeholder mapping.
In the next instalment we will look at some of my favourite tools for helping to create a business case that serves it’s purpose.

Read part one part two Read part three Read part four
About the author
To contact the author you may email him on ed@thebridger.co.uk.

Adaptability - a key skill for a business analyst

Alex P — Tue, 17 Mar 2009 07:39:00 GMT

I have been pondering recently on the importance of adaptability for a business analyst.

Definition of adaptability

It seems to me that adaptability is a key skill of a business analyst because no two projects are alike. It’s not possible to apply a template approach to every project situation with which you are confronted.

However, I looked up synonyms for adaptability and came across these - malleable, pliable, adjustable, compliant, easygoing. You need to be adaptable but these are sending out the wrong message - although it is important to be adaptable, equally you cannot be a pushover! The business analyst must have a set of principles that they work with and these should not be contravened.

Example

In a recent engagement, an existing project was in flight but hadn’t accommodated the requirements of another business unit as they had been unable to supply resources at the time requirements were being gathered. It was also understood that many of their requirements would match the existing set as the project was driven by new regulations that introduced new processes which all would have to follow.

I was invited to gather their requirements but time was of the essence as the existing project had progressed and was completing high level design. Any delay could risk the main project and there was a fixed deadline when the new regulations had to be met.

I recognised that we had to attempt to dive to the detail during requirements gathering in order to rapidly identify the ‘hot areas’ where the differences existed or were most likely to exist. We agreed an approach that would start with the new business process walk through without an analysis of the project goals and/or identification of the critical success factors. Once the hot areas were established, we would drill down into the detail and identify detailed requirements in these areas. This was the adaptable bit.

One principle I operate is to ensure that the early stages of the project are conducive to successful business acceptance testing. This means that all the requirements must be complete, clear, unambiguous and measurable (for more on this, see Requirements engineering and quality). In order to achieve this, the critical successs factors, business objectives and all of the existing requirements would need to be revisited after this accelerated approach. It would have to be analysed and documented whether and how they would apply for this new business unit.

Dogma

I have mentioned before (and will again) that I don’t like dogma. Anything that encourages you to follow an approach blindly feels, instinctively, that it has to be wrong. However, there is a paradox as I have certain rules that I see as inviolable which must always be observed.

The difference is that these are principles which don’t dictate how you go about something but it is important to be aware of them at all times. At any time in a project, you can refer to these principles, consider if you have adhered to them and measure your success on the project against these.

These are just my views - as ever, I would welcome any other points of view.

Alex Papworth, (this was taken from www.businessanalystmentor.com)

3 Guaranteed ways to become a better BA

Craig Brown — Fri, 30 Jan 2009 11:22:00 GMT

In recent years I have done three things which have really ‘ramped up’ my performance at work.

In my readings online, in books and journals I have learned that there is serious researched evidence that these three things are possible some of the best ways to improve your skills and ability at work (particularly in a thinking job like ours.)

These three things are relatively cheap, the tools are only a click or two away right now and only take a small amount of time on an ongoing basis.

And I am going to tell you what they are for free.

But before I do I have to warn you that most of you won’t be able to achieve this cheap and easy path to career success.

Most of you (research suggests over 95% of you) simply won’t have the motivation and desire to take the first step. Why is that? Probably because complacency and inertia are powerful forces.

I have a close friend who is both very smart and creative. But he has a lousy McJob which bores and frustrates him (as well as not paying very much.) But no matter how much I try to convince him to use his smarts, charm and wit to move onto something more rewarding he simply refuses to budge, following the patters and routines he has for years. That’s a shame for him. And possibly it’s also a shame for you.

The good news is that you are reading this.

To have gone to ModernAnalyst.com and sought out information on how to improve your career puts you in that 5% of people who really are going to try to do better.

But five minutes browsing does not make you a top-gun BA. You’ll need to make a personal commitment to yourself; to change and to do the activities it takes to change.

Are you up for it?

Great! Keep reading.

These three things are all based on research from psychology and neuroscience, as well as being observations that managers and trainers have had over the last few years (decades?)

They are based upon a few principles that you are probably already familiar with.

We learn better in groups
Public speaking is scary because we don’t want to look silly
Teaching is the best form of learning

Do these phrases ring true with you? If not, maybe take an hour or two to go research these ideas online.

Or you can quit now. Your choice.

If you are still with me, I’m ready to tell you my three very special secrets to mastery of the BA profession, and then explain briefly to you how each one will help.

Participate actively on forums like Modern Analyst & Sign up to a few message groups in your field
Start your won blog (or blog here at ModernAnalyst) and do it on a regular basis
Find someone to mentor or coach

Stop for a moment and reflect on these recommendations.

Do you feel vague hints of “yes that‘s a good idea, but how do I start?”

Fine. We can work with that.

Let me explain a bit further.

1. Participate

Participating with groups such as Modern Analyst (and maybe a local or regional BA community) expands your horizons and introduces you to new ways of thinking.

Also discussing ideas means you learn from the conversation. And by that I don’t mean you turn up and read/listen. I mean you participate. Put up straw man ideas for discussion, or ask questions if you don’t have a strong opinion on a topic.

At the very least you have one question you want to know the answer to. “How can I best tackle tomorrow’s work activity?”

Ask this one a few times and you’ll be amazed at how much more you’ll want to discuss.

2. Blog

Blogging achieves some of the benefits of community participation, but develops other skills also. Forums and meetings are conversations where ideas are exchanged. Blogs tend to be more one way messages. You speak to an unknown (at first) audience.

This teaches you to write well. You get concise and learn to structure your thoughts in a way that is digestible for your audience. (Erm, yes this is a long post.)

As a BA your job is all about good written and verbal communication. This is a massive opportunity for you. Don’t waste your time.

Go straight to google’s blogger, to ModernAnalysts Blog home page, or to any of the other free blogging tools out there and sign up today.

Make your first post before you go to bed tonight. And then make a commitment to post at least once a week for 3 months.

If you are stuck for a first-post topic try the theme of “What did I learn this week?” Everyone wants to hear Lesson Learned. Especially me.

While you are at it you can link back to my blog at BetterProjects (here) and I’ll tell my share of the BA world about your new blog.

3. Mentor or Coach

As I said above, teaching is a great way of learning. Coaching and mentoring also gets you to focus on the people side of the business, and to hone your ‘people change’ skills.

Additionally, by sharing your knowledge around you help your personal ‘professional community’ get stronger. And you get the feel-good rush of helping someone. And the list goes on.

So, are you in?

I hope so.

Craig Brown

Better Projects

26 reasons why projects succeed or fail

Craig Brown — Tue, 25 Mar 2008 05:14:00 GMT

There are several studies out there that identify why projects go wrong and what you have to have in place to make sure they have a chance. Naturally the readers of Modern Analyst (and BetterProjects.net) are aware of the importance of good requirements management, a theme which permeates the list below, culled from a range of PM literature[1].

You will have heard of many, if not all of these issues before. Today I want to put them into a new context for you; that of the business analysts’ role on projects and what you can do to help your project achieve success.

Consider firstly the degree to which the business analyst can control, influence or block each of these issues, then reflect on your personal experience. What techniques have you applied in these areas, and how effective were they?

Critical Factors for Projects

Support from senior management
Clear realistic objectives
Strong/detailed plan kept up to date
Good communication/ feedback
User/client involvement
Skilled/suitably qualified/sufficient staff/team
Effective change management
Competent project manager
Strong business case/sound basis for project
Sufficient/well allocated resources
Good leadership
Proven/familiar technology
Realistic schedule
Risks addressed/ assessed/ managed
Project sponsor/champion
Effective monitoring/control
Adequate budget
Organizational adaptation/culture/ structure
Good performance by suppliers/ contractors/ consultants
Planned close down/review/ acceptance of possible failure
Training provision
Political stability
Correct choice/ past experience of project management methodology/tools
Environmental influences
Learning from Past experience
Appreciating Different viewpoints

Now your mission, should you choose to accept it, comes in two stages.

Firstly comment below sharing your stories, and secondly go back to your project and see what you can do differently to help your team deliver success.

[1] I picked up this list from a doctoral thesis I read, but the copy I saw did not have the Author’s name on it.

Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Recipe Redesign: There Is No Box, Only Possibilities

Top 20 Crucial Angular Best Practices to Embrace in 2023

Key Features of Angular

Top Angular Best Practices to Adopt in 2023

Use Angular CLI

Upgrade to the Latest Angular Version

Follow the Single Responsibility Principle

Optimize Change Detection

Lazy Load Modules

Use AOT Compilation

Follow a Consistent Folder Structure

Leverage Reactive Programming

Minimize the Use of ngIf and ngFor

Implement ARIA Accessibility

Optimize Bundling and Tree Shaking

Proper Error Handling

Use Angular Interceptors

Apply Angular Forms Effectively

Perform Unit Testing

Implement Server-Side Rendering (SSR)

Utilize Angular Material

Keep Third-Party Libraries Updated

Implement Content Security Policy (CSP)

Monitor Application Performance

Conclusion

6 Differences Between Data Exploration and Data Presentation

1. Audience — Who is the data for?

2. Message — What do you want to say?

3. Explanation — What does the data mean?

4. Visualizations — How do I show the data?

5. Goal — What should I do about the insights?

6. Interactions — How are data insights created and shared?

Finding the Middle Ground: Data Storytelling

Top 10 Mistakes in Requirements Elicitation

What Skills do You Need to Become a Business Analyst?

Sections in a Functional Layout for an Entry Level Job Resume

8 Ways to Be a Badass Business Analyst Employee

Every Business Analyst Must Negotiate Like a Pro

From Developer in India to Business Analyst Abroad

Oh...I wish I knew this before!

What do you do?

Communication Is a Two-Way Street

Want to be an effective professional? Follow up!

How to identify a good (and bad) Business Analyst?

Do you want stakeholders to trust you?

Applying Agile principles to requirement analysis

Are you the first and only one?

What Every Business Analyst Can Learn From Journalism: The Art of Intelligent Questioning

Feedback cycles, meet deadlines. NOT good bedfellows

The Social BA - 5 Reasons to get Active Online

Simplicity and Elegance: Expressing Your Core Competencies

Executive Coaching and Debriefing for Corporate Leadership Development Programs

A dressing down for business analysts

Complexity: The Execution Challenge You Don't See

BA Careers - Is industry experience more important than Analytical skill?

Career Possibilities for Business Analysts-expanding your horizons

Enter the Business Engineer

The ‘Business Engineer’ – who are they, what do they do, and why you want to know them.

Who

What

Why

Being New 101

IT Black Ops

Building Credibility With Your Team

BA World Sydney - A review

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Tips for managing business meetings

Video: Get things done with Autofocus

When a business case is not a business case

Adaptability - a key skill for a business analyst

3 Guaranteed ways to become a better BA

26 reasons why projects succeed or fail